If you have opened the web test and execute a performance test list, which includes this test, the performance details will not be updated automatically in the Performance tab.

You need to reopen the web test and go to the Performance tab to view the updated details.

There are times where test studio throws this exception described in http://feedback.telerik.com/Project/161/Feedback/Details/121035-path-too-long-on-backup-problem

[04/24 11:48:37,Telerik.TestStudio.RemoteExecutor.exe(5092:133),TestStudio] AutomationHostState.StoreToFile() : EXCEPTION! (see below)
     Situation: AutomationHostState.StoreDomOnDisk
     Outer Exception Type: System.IO.PathTooLongException
     Message: The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.
     HRESULT: 0x800700CE (Official ID (if app.) = 2147942606, Error Bit = FAILED, Facility = FACILITY_WIN32, Code = ERROR_FILENAME_EXCED_RANGE)
     Call Stack:
          at System.IO.PathHelper.GetFullPathName()
          at System.IO.Path.NormalizePath(String path, Boolean fullCheck, Int32 maxPathLength, Boolean expandShortPaths)
          at System.IO.Path.NormalizePath(String path, Boolean fullCheck, Int32 maxPathLength)
          at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)
          at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize)
          at ArtOfTest.WebAii.Design.AutomationHostState.StoreToFile(String filePath, Object value, String traceMethod)

[04/24 11:48:37,Telerik.TestStudio.RemoteExecutor.exe(5092:133),TestStudio] AutomationHostState.StoreImageBytesOnDisk() : EXCEPTION! (see below)
     Situation: AutomationHostState.StoreImageBytesOnDisk
     Outer Exception Type: System.IO.PathTooLongException
     Message: The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.
     HRESULT: 0x800700CE (Official ID (if app.) = 2147942606, Error Bit = FAILED, Facility = FACILITY_WIN32, Code = ERROR_FILENAME_EXCED_RANGE)
     Call Stack:
          at System.IO.PathHelper.GetFullPathName()
          at System.IO.Path.NormalizePath(String path, Boolean fullCheck, Int32 maxPathLength, Boolean expandShortPaths)
          at System.IO.Path.GetFullPathInternal(String path)
          at System.IO.File.InternalMove(String sourceFileName, String destFileName, Boolean checkHost)
          at ArtOfTest.WebAii.Design.AutomationHostState.StoreImageBytesOnDisk(String projectResultsPath, String fileRelativePath, String expectedImageRelativePath)

There was a MSDN blog by Kim Hamilton that suggested a possible solution to this issue.  http://blogs.msdn.com/b/bclteam/archive/2008/07/07/long-paths-in-net-part-3-of-3-redux-kim-hamilton.aspx

Please see if this exception handling is feasible.

When using Test Studio for API standalone, the coded step is deleted after reopening API project.

Steps to reproduce:

1. Open Test Studio for API standalone and add a coded step (C#)

2. Save project then close it

3. Reopen the project in Test Studio for API standalone and the coded step is no longer there and the Test Case will now show a VB# instead of C#

4. Recreate the coded step and the method will show "A class with this name is not found in the test's code-behind file"  

6. Click on open Code-Behind and the project will crash.

Note:  API Test as Step in Test Studio works as expected and reopening the API project within Test Studio doesn't delete the coded step.  However, we create a “common API project” that is shared with the QA team then imported into new test studio project.  We have a workaround but not ideal which is to create the API project within Test Studio and copy the API test folder to share with the QA team.

Steps to reproduce: 

1. Record a test against the demo page. 
2. Select an item from the DropDownList control.
3. Note! the recorded step to select an item from the dropdown is not the KendoAngularList one, but is the KendoListBox. 
4. Execute the test.
Expected: to pass the test.
Actual: the correct item from dropdown is selected, but the step is failing with unexpected error. 

Workaround to resolve the issue: Open Project Settings and disable the Kendo UI jQuery translators (or the ListBox one only), save the changes and re-record the respective steps in a new recording session. This will record the correct steps and the execution should work as expected. 

Custom WPF application with specific control - ViewBox, causes the highlighting to be misaligned. 

In case the ViewBox control is removed from the application structure, the highlighting works as expected. 

It would be useful to have a method where you could specify global/environmental variables/parameters that is separate and independent from the data driven feature. These global parameters would be avalaible to all tests using the Data Driven interface of binding values to test steps, but would not be mingled in the data source itself. This way you can create a data driven test that runs iterations but keep the environmental static data e.g. userid's to login as, separate from the data itself.

See the screen shot.

There are two annotation markers. For some reason, a "MouseClick:LeftClick" will appear, as it should, but then it sticks there, even as 10 or 12 other steps execute and their annotations come and go. Sometimes another MouseClick:LeftClick will appear and the old one will go away and then the new one will stick. But this does not happen every times. Sometimes a new MouseClick:LeftClick annotation comes in and goes away and the old one is still hanging around.

This happens will almost all of my scripts.

Is it because some of the mouse clicks are from recorded steps and some are from code steps? This is just a guess.

It is rather difficult to debug tests that use nested sub-tests. You can't set a breakpoint in a sub-test (it's ignored) and you can't "Step over" and "Step into" similar to how source code debugging works in Visual Studio.

Hi guys,

We're using Telerik Testing Framework for automation and running tests primarily against IE browser and since we have security policies enforced on clients, tests started to fail more often with ApplicationException on start.

After some investigation we found that in LaunchNewBrowserInstance() function in Core.Manager has hardcoded timeout to 5000, which is not enough now for IE to respond. As you can see in the code below, everything is using 'timeout' variable except 'Connector.Attach(ref handle, 5000);' - it uses hardcoded timeout to wait:

internal static object LaunchNewBrowserInstance(
      int timeout,
      ProcessWindowStyle windowStyle,
      string pipename,
      string url)
    {
      string str = string.IsNullOrEmpty(url) ? "about:blank" : url;
      try
      {
        ProcessStartInfo startInfo = new ProcessStartInfo()
        {
          Arguments = (InternetExplorerActions.MajorVersion >= 8 ? "-nomerge " : string.Empty) + str,
          Verb = "open",
          WindowStyle = windowStyle,
          ErrorDialog = false,
          FileName = "iexplore.exe"
        };
        System.Diagnostics.Process process = System.Diagnostics.Process.Start(startInfo);
        TraceInfo.Framework.ReportProcessLaunched(process, startInfo);
        IntPtr handle = InternetExplorerActions.WaitForIEFrameFromProcess(process, timeout);
        TraceInfo.Framework.WriteLine("Attempting to attach on IE frame (HWND={0})...", (object) handle);
        Connector.Attach(ref handle, 5000);
        System.Diagnostics.Process currentProcess = System.Diagnostics.Process.GetCurrentProcess();
        int num = currentProcess.Id;
        if (currentProcess.ProcessName == "ArtOfTest.Runner")
          num = InternetExplorerActions.SafeGetParentOrCurrentId(currentProcess);
        Connector.InjectCode(handle, InternetExplorerActions.ArtOfTestPlugin, pipename, num.ToString(), true, timeout, "");
        return (object) null;
      }
      catch (Exception ex)
      {
        throw new ApplicationException("Exception thrown attempting to launch Internet Explorer. Please make sure Internet Explorer is properly installed and you are able to launch it.", ex);
      }
    }

This is likely the cause, why our increased timeout settings are ignored and test fails shortly after start, even if we increase timeouts significantly. Visually, it looks like IE is doing some background job and is not responsive for some period of time and 5 seconds is not enough to wait. So, could you change the code to respect 'timeout' instead of using constant number?

We've been using Telerik Testing Framework for a long time already and from time to time had this issue, but workaround it by catching exception, killing browser and trying to launch it again. But now that trick is not helping anymore, the majority of tests fails with this exception on start.

This fix is really simple and will save us a lot of time, trying to invent some new solution to make IE more responsive on start.

Thanks,

Oleksii

On a data driven web test, setting the DataRange property to the example "SingleRow" causes Visual Studio 2017 to crash.  I have three rows of data in a data table that are bound to specific steps of my test.  I was attempting to limit execution to only one row temporarily. Using SingleRow or 'SingleRow' causes Visual Studio 2017 to crash with the following stack trace as found in Windows Event log.  I was able to successfully use '1:1' or ':1' as a work around.

I had some issues with Test studio projects opening in VS.  I reported this issue to Telerik Support on Ticket ID 755261.  The main thing from the ticket to note is that the project would backup would throw this error:

[11/07 00:23:37,devenv.exe(6016:1),ProjectModel] Project.BackupProject() : EXCEPTION! (see below)
     Situation: Error creating project backup
     Outer Exception Type: System.IO.PathTooLongException
     Message: The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.
     HRESULT: 0x800700CE (Official ID (if app.) = 2147942606, Error Bit = FAILED, Facility = FACILITY_WIN32, Code = ERROR_FILENAME_EXCED_RANGE) 

With this in mind, I moved all automation projects' folder as close to my base C drive that I could instead of having it on my desktop with filepath of C:\users\name of user\folder... 

Even after moving my folders, I still had to shorten my automation folders to be a single folder deep and have my tests have shortened file name that I codified to make some sense to what the test should do.  I have this problem from R1 2013 and still have this issue.  

Though I am not sure if others have had this particular issue happen to them, I would think that this problem causes me as a user to lost the flexibility of having my projects in a convenient location on my computer instead of having to dig through to find it.