When using the recorder typing text in a RadSearchBox it records action specific to that element type. This fails when my desktop if locked with a Win32 error which I assume is because it is locked.
First of all, isn't it possible on your end to detect this scenario and provide a detailed error message (not Win32) or even attempt to fall back to a mode of setting text that doesn't require the desktop be unlocked?
Second, the properties for a RadSearchBox action have TypingSpeed which says it is used "when SimulateRealTyping is set", but I don't see the SimulateRealTyping property for this element.
Third, I tried to create an action on the element to just set the text. While it has an "Enter text" action listed under quick actions, it actually fails when run with the following error. "Target '[Element: 'div:112' (id=ctl00_cphM_scMain_sbKeywordSearch)]' is not a supported element to set text to."
I'm not sure if it is even going to be feasible to convert all of our tests to run with the desktop locked, but this is the first one I am working on and am already running into a problem. I wish I had been aware of this before since the goal is to schedule them to run unattended.
Recorder
RadSearchBox('ctl00_cphM_scMain_sbKeywordSearch'): text 'Test' entered in Searchbox input
Manually added step
Enter text 'Test' in 'KeywordSearchBox'
3 Answers, 1 is accepted
Hello,
Thank you for contacting us with those questions. I will be happy to provide more details and try to help you automate this scenario and execute the tests remotely.
- Test Studio is designed to execute with an active user session at all times. Otherwise, dialog handling and desktop actions will not work and will result in different behavior. This is actually a limitation from Windows for UI testing and I would advise you to have a logged in user on the execution machine during test runs.
- I tested the RadSearchBox on my end as well and since this element has many events, that need to be triggered, this step acts a SimulateRealTyping. We found that it is necessary to have the real user simulated, otherwise, the automation of this search box will most likely fail. This is why you are seeing the TestingSpeed option in the properties pane.
- I am not familiar with the application under test and I am not sure which is the element you enter text against. What you can try is, use the Recorder's Highlighter and hover over the "input" menu and click on Add to Elements button. Once you have added the "input" element to the repository, you can record an "Enter Text" step from the Step Builder and see if that will help with the test automation. As I mentioned above, there are many events that need to be triggered for this control and as a result this approach might not work.
There are a some ways to keep the execution server awake and prevent it from locking the desktop. You can enable the Keep Machine Awake option on the execution server and as long as the scheduling client is running, the execution server will be active. You can also enable the Reconnect to Console on Disconnect, based on your environment and setup. There is another option that you can explore, using a total of 3 machines, in order to keep an active session running.
My understanding is that you can still have the scheduled jobs run unattended, but still with an active user session on the execution machines.
I hope that the above details will help you find the best solution for this scenario. In case you need further assistance, please do not hesitate to contact us again.
Regards,
Plamen Mitrev
Progress Telerik
Rank 1
OK, if I'm running into issues with something this simple I don't think this is the way to go. I do think it is a bug if the action appears as an option but doesn't actually work, also, it would be helpful to people if the Win32 errors were more descriptive.
I'm now focusing on maintaining the active session which was already my plan B.
Hello,
I noticed that there is one additional property that is also missing for RadSearchBox text entered step and that is the ScrollToVisibleType. I created a public bug report on your behalf and our engineering team will investigate it further.
The Win32 errors, that could happen during execution, are actually thrown by the Windows and not from Test Studio necessarily. There is still some additional information in the stack trace and the step failure details, which can be very helpful in troubleshooting the misbehavior. It is expected to have an active user session on the execution server during UI testing. This limitation comes from Windows and applies for desktop actions and dialog handling. Other steps that use JavaScript to enter text or click a button are not affected by it.
Thank you for your feedback and understanding. I remain available to continue our discussion, if necessary.
Regards,
Plamen Mitrev
Progress Telerik