There is no direct method in the Testing Framework, which can be used to scroll the RadGanttView control in WPF app. 

It will be useful to explore such implementation.

When it comes to automated testing of the API, it would be useful to support human-readable (markdown/html/pdf) formats.

We (dev & qa team) want to use the generated output file as documentation to make the test cases & results easily accessible for the product manager and colleagues without licensed access. The supported xml file already contains a lot of information about the tests.

The human-readable version does not need to be multilingual, English is perfectly sufficient. The format only needs a standard like markdown, html or pdf.

C:\>"C:\Program Files\Telerik\Test Studio for APIs\Bin\ApiTesting\runnerconsole\Telerik.ApiTesting.Runner.exe" test -p "C:\DemoTests" -o "C:\result.md" -f markdown

Hi Team,

I would like to be able to use a cloud based browser platform similar to BrowserStack, Sauce Labs, Ghostlab, Browsershots, etc. In order to avoid setting up massive VM farms to distribute browser iteration testing. 

Thanks!

It would be useful to support the generated output file additionally in a human-readable format (markdown/html), when it comes to automated API testing.

We (dev/qa team) would like to attach the file to the story as documentation of the test case. So that the product manager or other colleagues (without license access) can easily take a look at the covered cases. 

The current xml output (sample attached) already provides a good overview and could be extended with background information in some places (for example <action>).

At this point it is possible to run a WPF application with arguments only as a workaround - starting a separate process in a coded step as given in this example.

It would be more useful if this feature is implemented when configure the WPF app in the test.

I am logging this feature request on behalf of Eugeniy Gorbovoy.

Currently the timeout setting of http requests allows only numeric input and defaults to 2000 ms when left empty. The initial plans are to implement a global project-level setting for timeout that all http requests should inherit (unless locally overwritten). (I hope we will have it delivered in some of our releases in the near future.) This should handle most cases when users want to manage the timeout from a single place instead of manually increasing it for every new http step they create.

Still the idea for accepting a reference to a variable seems appealing since some users might prefer to have several "tiers" of timeout rules across the test project and manage them using variables. Any comments and shared use-cases are appreciated.

Get the response body in the API test results, when it is executed from the API command line runner. Currently, the response body is only available in the Test Studio for APIs user interface and it is not outputted in the results.

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.

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.

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

The test list events are fired in case of running on the scheduling server, however the problem occurs in case of running on the execution client setup (out of the server).

Steps to reproduce:

1. Create your own execution extension.

2. Override OnBeforeTestlistStarted and OnAfterTestListCompleted.

3. Create a test list and run it remotely.

Expected: OnBeforeTestListStarted and OnAfterTestListCompleted are called.

Actual: OnBeforeTestListStarted and OnAfterTestListCompleted aren't called.