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.
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>).
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 one schedules a test list and the tests execute with the rerun failed tests option, there is only a limited number of things that can happen.
1) a test may pass.
2) a test may fail once but pass the second time.
3) a test may fail twice.
4) a test may not run.
My suggestion is that, if these are the four types of result, report only this.
When you say this:
Run Summary: 25 of 25 test(s) run; 22 passed, 3 failed, 0 not run.
there is ambiguity. It is not clear what happened. It could instead say:
Run Summary: (#) test(s) run, (#) passed, (#) failed but then passed, (#) failed twice, (#) not run.
If the summary is in the second form, there is no ambiguity.
It would be helpful extract the current selected value of a RadDropDownList, so it can be compared to the expected value. This is commonly used to verify if the selection was successful.
Please consider adding such extract steps for other similar controls.
Once you connect to a pop-up window, you can not switch back to the previous one, until the pop-up is closed. Some test scenarios will benefit from the possibility to switch back and forth.
Please consider this feature for next releases.
Currently, when a step in the API test fails, the whole test is stopped.
Please add the continue on failure option for steps in API project.
It would be nice if there was a way to avoid simulating real typing for a search box. There is no option to enable/disable it, but it is clearly using this behavior. I've tried a workaround of entering text directly in the input element, but it doesn't seem to register it when this technique is used. I don't see how a textbox can be made to work without this behavior but a search box cannot.
Simulating real typing tends to be the most fragile part of our tests, and all we really need is to enter text and then search. It also slows down the tests quite a bit vs. just setting the text directly.
Tests that have Not Completed tests, shouldn't list the overall test as Pass or Fail....rather it should set the overall run as "not complete"
In addition - when loading not completed tests within test runs, they are just shown as fail with no background and white text. The run is listed as pass if there are no fails but existing "not completes".
Recommendation to add Not Complete as overall result in addition to individual tests that are no in a passed or failed state
Currently Test Studio updates only the necessary tests and resources to the storage server. When the test execution starts on the execution server, Test Studio will download everything available in the storage server.
Please check how this can be optimized to ensure that there are all the necessary resources for the test execution.
Conditional statements (if, while, and such) should be able to use an extracted values as a condition.
Also multiple conditions will be very useful in some cases.
I think it would be neat to be able to view / edit markdown files within a project within the Test Studio application. Being able to see a markdown file in the project list, and have them open in a editor tab so you can review / make edits.
For example I create markdown files that have high level summary's of what each test completes, or potential helpful debugging information on a particular test.