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>).
Trying to open a RadComboBox with
var csBox = Window.Find.ByName<RadComboBox>(ComboBox);
Observing the automation shows we are waiting no time for dropdown to open and I am getting exceptions claiming there are no items in the list.
The cause is related to the fact that the public void WaitDropDownAnimation(int millis) method of Telerik.WebAii.Controls.Xaml.Wpf.RadComboBox is not working as expected.
Workaround: You can use Window.Find.ByType<RadComboBoxItem>().Wait.ForNoMotion(milliseconds); before selecting the item from the dropdown.
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 I close the Remote Desktop connection, the Test Runner on my VM reconnects to the Windows session successfully, but it does not set the correct resolution.
It seems to default to a base resolution and not the one from Change Console Resolution settings in the Test Runner.
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.
Why do some extract actions have expectation properties? Isn't the purpose of an extract just to get whatever value is set at the time and put it into a variable for later use (typically verification)?
For example, the RadDropDownList has the built in action of "Extract - RadDropDownList: all item count is '19'". This creates a step like this: "RadDropDownList('ctl00_cphM_ecAddContact_ddlCategory')Extract item count into DataBindVariable $(CphMEcAddContactDdlCategoryDiv)". The step properties have CompareType and ItemCount.
Interestingly, in my test of a drop down list with 19 items, I changed the ItemCount property to 999 and ran it and the step passed successfully.
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