Is this normal? How can we correct this?
The telerik test studio version is : 2016.3.928.0
5 Answers, 1 is accepted
Allow me to provide some details about element finding logic and filters, which can be relevant to your case. You can view and edit the find element logic of each element in your tests. Also, keep in mind that if there are multiple elements that fulfill the conditions in the filters, Test Studio will use the first element in the DOM.
I assume that the behavior you are experiencing is normal and thus, there are ways to solve this problem without writing any code.
- When there are changes in the page, you can simply record the test step again. To do this, you can right click on the previous test step and select Run -> To Here as shown in the attached image record-run-to-here.png. After all steps to this point are executed, the browser is ready to record new actions. You can record the needed step and close the browser to stop recording. Test Studio should update the find logic for this element, if possible and this can fix your test.
- You can edit the filters for the element by more adding conditions like title, class, id and others. This allows you to distinguish between two similar elements in the DOM.
- Alternatively, you can use chained find expressions to filter first a parent, which is close to the element and has unique identifier like id for example. Then by using another set of filters, you could be able to select the required element. Chained filters are applied consecutively to narrow down the element in the DOM. Note that if there are multiple elements to fulfill all filters, the first element to match all of them, will be used. You will need to update the filters until you get the necessary result.
I hope that the above suggestions will help you resolve the problem. Please do not hesitate to contact us again.
Thanks for all the details:
The input it's searching by using id and tag please see attached Screenshot.png.
We tried also to record again the test but the result is the same.
What is strange for me is that the html for desired element to be clicked is:
<img id="imgctl00_MainContentHolder_utpActions_actionExcel" src="/App_Themes/Orange/images/Icones/ExcelBlue.png" align="ABSMIDDLE">
and the div that it's loaded in the page is:
<a href="some url" target="_blank" class="dw-sm-icon-container" onclick="someClickEvent"> <span class="dw-sm-icon"></span> </a>
Somehow it's jumping and clicking on the second one.
Thank you for the provided information.
The behavior of the test is indeed unexpected and in order to provide additional guidance, I will need some further details from your side:
- Does the test fail during execution? If that is the case, can you please attach the step failure details for it? If the test does not fail, please attach the execution log. This way I will get a better overview of the test steps.
- Can you record a short video, of the test quick execution, with annotation turned on (step 5 in this article)? With it, I will be able to see what actions are executed, especially for the step that is misbehaving.
- It will be very helpful, if you can provide an example application for us to test with and reproduce the faulty behavior.
At this point, I can suggest that you try and remove the filter by id and replace it with filter by the attribute src with the exact value "/App_Themes/Orange/images/Icones/ExcelBlue.png" or containing only "ExcelBlue.png" . Such changes may fix the issue, but the step failure details/execution log should provide more details about the test execution. Alternatively, you can also try to use chained find expressions to add additional filter to narrow the DOM to a parent element and apply the find element logic to this element only and not the whole page.
Thank you for your cooperation and understanding.
Sorry for the late reply. I was trying to reproduce the scenario since the application has some sensitive information.
In the meanwhile i found this post: https://www.telerik.com/forums/simulate-real-typing-causes-focus-lost and the solution provided it's working .
Since the impact was on 100+ tests we did an workaround: We added a global step to wait for the div to be loaded.
I am glad to see that you managed to fix your tests.
I did not understand what was causing this misbehavior and I can only assume that there was a static header, which was preventing Test Studio from clicking on the correct element. If that is the case, you could try to convert the failing step to code and change ElementTopAtWindowTop to ElementBottomAtWindowBottom in the ScrollToVisibleType method. Then, the browser should scroll the element to the bottom of the page. As a result, it will not be hidden behind a static header and the click or type actions should be successful.
If you have any further questions, please do not hesitate to contact us.