I've seen this issue in a multiple forum posts and feature requests, but I'm not seeing a good solution for the RadSearchBox. Maybe I'm missing something.
The following feature request has a post from 2019 saying a ScrollToVisibleType was added, but it doesn't seem to have made it to the RadSearchBox. The RadSearchBox requires simulated real typing (no option to view or disable, and I've been told it is required to be this way in another issue). I have pages with a fixed header at the top, and depending on the size of the browser and number of items on the page it ends up scrolling to the bottom of the page and obscuring the control under the header. Ideally it should do nothing as the control is at the top of the page and visible before this step runs.
https://feedback.telerik.com/teststudio/1378898-only-scroll-to-visible-the-target-element-when-necessary#
5 Answers, 1 is accepted
Rank 1
Rank 1
Hello,
I am sorry to hear about the encountered issue. I did some tests on my end and reproduced the misbehavior against this public page. This is why I created a public feature request on our behalf and our engineering team will investigate it further an plan for future releases. The feature request that you linked is done for steps that are not recorded with translators. The new feature request is specifically for steps with translators, like the RadSearchBox.
There are 2 different approaches to automate this test scenario. I will share more details below and a sample Test Studio project for reference.
- Write the text directly to the <input> element. To do so, you need to navigate to the page with the recorder attached and enable the highlighter. Then record a verification step of any kind against the input element. This will also add that element in the elements repository and you need to add Action -> Enter Text step against that element from the step builder.
The newly added step can be configured to simulate real user typing and also has the ScrollToVisibleType option in the properties. In your case, there is a static header, which goes over the RadSearchBox, so this option should be changed to ElementBottomAtWindowBottom. - Another option is to use a coded step to scroll the element to the bottom of the page and simulate the real user typing. You can explore the attached test CodedMethod for more details and a sample code.
The scroll action helps us ensure that the element is visible on the page and it can be clicked. We are constantly trying to improve it and allow customization to fit all needs.
I hope that the above suggestions will help. Please do not hesitate to contact us again, if you need further assistance.
Thank you for your feedback and understanding.
Regards,
Plamen Mitrev
Progress Telerik
Rank 1
The first option is more palatable than the second. I tried that, and it seems to work, but now I have to convert a number of steps. Thankfully I don't have a ton of tests at this point or this would be a lot of work.
I'd argue this is more of a bug than a feature request since in many cases just doing nothing would be preferable and not cause this issue, but I will go with the workaround for now since it seems to be functionally equivalent to what I was doing but just takes more effort.
Hello,
I am glad to know that the workarounds that I suggested are working for you. I agree that they are not ideal for large number of tests that automate this action and that is why we will check for a solution in our future releases.
Thank you for your feedback on this issue.
Regards,
Plamen Mitrev
Progress Telerik