I thought I had this figured out, but TS has proven me wrong. My problem is with find expressions and has happened multiple times. When I fix an expression and validate it, TS says it can find the element. However, when I run the test, the same step fails with the same cant locate error. When I look at the find expression, its still the one I corrected but now TS doesnt recognize it as valid expression.
Another issue I'm have has to do with 'Enter text'. All I get is errors like:
Target '[Element: 'ul:0']' is not a supported element to set text to.
Thanks
2 Answers, 1 is accepted
Hello Steve,
I am sorry to know you experience such difficulties and will assist you further with that.
I will first focus on the example error you listed about the Enter text step. It seems that you used a target element, which points to a <ul> control in the html - this is an unordered list, under which there are list items listed. Usually this is used in the dropdown type controls to list the items from the dropdown menu. The error you see indicates that this is no valid element in the html, which accepts text and thus Test Studio cannot set text to it.
If the scenario is related to handling a dropdow, here are few notes to have in mind. Depending on the control Test Studio might be recording special type of steps like KendoInput: Toggle Combo, and KendoListBox: Select item by text. These steps are generated from the built-in translators in Test Studio. The second mentioned step is actually targeting the unordered list in which are the dropdown options and if you have used this element from the Elements Explorer to add a step through the Step Builder, you might stumble upon this error.
The details shared here are only an assumption based on my experience. To allow me analyze this in further depth and help you with this topic, I will need the failure details for the errors you can't sort out and the test, which generated this. Even if I am not able to execute the test on my end, the DOM snippet at the time of failure and the elements find expressions listed with the test elements, will help me provide more precise information.
So, if you need further assistance for this case, we can switch the communication to a private support thread where you can share the step failure details (these can be exported to a zip) and the test files - these are three or four files in the File Explorer with the name of the test and different ending.
Let me know in case of any further questions. Thank you for your cooperation in advance.
Regards,
Elena
Progress Telerik
Rank 1
Iron
Hi Steve,
Thank you for your cooperation. I shared a cloud folder at your disposal via email. Please, let me know if you have troubles accessing this one.
Regards,
Elena
Hi Steve,
Thank you for your sharing the step failure details.
My overall impression for the shared tests is that these are not quite reliable for execution because the wait steps or verifications, and execution delays are insufficient to ensure the page is in the correct state when sending the next action towards. If you revise the images on failure and compare these with the expected image, it seems that the test didn't reach the correct page for some of the actions.
Therefore, my first suggestion will be to insert such steps in between the recorded steps. The general advise you can follow is to insert a wait or verify step whenever something is changed on the page. For example, text is entered in a text field - after that you can verify if the text was set as you expect it. Or, a dropdown selection was performed - check if the selected item is the desired one.
A wait, or execution delay step, is helpful when any click loads a new page, or a new form on the page - inserting a wait for visible step (using an element from the new page/form) after this click will ensure that the new page or form is loaded and then the rest of the actions are sent towards. This will improve the stability of the test runs.
One more thing to consider is the scaling on the monitor you use - there is a note in the logs that this is not set to 100%. For best recording and execution experience, though, we recommend the 100% scale. Here is how you can change this for your display.
As to the find expressions used, these seem to be uniquely pointing to the elements on page, so once you setup the speed of execution, I assume you will not have troubles with not found elements any more.
The invalid control failure is related to the element targeted from the Enter text step and what it can be used for - this is a div searched by its index only, and div elements cannot accept typing. Probably there is an input control nested in the div and this is what you need to target. I will recommend you re-record the step and, optionally, carefully choose the element to set text to from the DOM explorer.
I hope these notes will be helpful for you to sort out the failures. Don't hesitate to contact me back in case you need further assistance.
Regards,
Elena
Progress Telerik