Once I have the browser up and running I don't need to start from 'Log onto URL'. Hence my high partial test run use.
I may be only running part of a test, but when the test is 500 steps its cumbersome to highlight the section I want to run, and where to stop.
It would be much easier to set a breakpoint, run the part of the test I need, and stop midway.
Every day, and usually many times a day I forget to turn it off and begin recording random steps. Then I have to go find them and delete them.
Once Annotations is on leave it on similar to the Debugger.
And with it leave the ms where it was.
Every time I log on it takes me a few minutes to realize Annotations is off.
Edit in Code:
If no change is made to the file do not convert it to custom code.
I believe the staff would get fewer help tickets caused by 'coded' steps.
Visual Studio and Azure pipelines - they only support unit tests to be associated with the test cases and not Test Studio tests. there should be some easy way to convert studio tests to unit tests(nUnit or Junit etc.). Else Azure CI/CD DEVOPS is incomplete.
A project's BaseURL appends a slash after the URL is entered into a Project's settings. This is not idea in environments where you URL's are parsed like the following: 1) Protocol: http:// 2) Environment: dev, uat or blank 3) Sub Domain: admin, shopping 4) Domain: mycompany.com So when the base URL for the dev test list is "http://dev" for example. It navigates to http://dev/shopping.mycompany.com. It would be preferable in some cases if the test would navigate to http://devshopping.mycompany.com. To achieve that, there needs to be a method to remove the appending slash from the Base URL.
As a workaround you should use quick execute button or F5
When I run my test that requires a button click event it works fine. However, when that same test is run from test list, it does not - the web page remains the same, with the visible button not being clicked.
Weird, this only seemed to happen after upgrading to 2022.1.215.0
Steps to reproduce:
- Record a sample test on https://demos.telerik.com/kendo-ui/textbox/index.
- Enter name in the KendoInput field.
- Add a step to verify the value of the KendoInput through the highlighting menu and execute these recorded steps.
Expected: Successful execution.
Actual: The test fails on the verification step and reports that the value of the KendoInput is null.
Additional note: If the verification is added for the input control (instead of using the KendoInput), it is executed as expected.
A specific coded steps test cause Chrome to be closed when trying to perform a partial run using Run->To Here.
The coded step before the navigate one is starting a proxy to log the traffic.
Sample project is provided internally.
There are no built-in translators for Kendo React controls.
It will be useful to revisit the story and evaluate the need of such translators.
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.
Trying to open a RadComboBox with
var csBox = Window.Find.ByName<RadComboBox>(ComboBox);
csBox.EnsureClickable();
csBox.SelectItem(1);
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.
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.