Yeah, Ui.Vision needs the Chrome and/or Firefox browser to run, and the browser needs a GUI environment to work.
The reason for this is that UI.Vision supports many more commands than Selenium IDE, and some of these commands (e. g. for PDF testing) only work in a real browser, and not in a headless (limited) browser simulation.
In addition, since the the headless browser used by selenium-side-runner is not a full browser, sometimes Selenium IDE tests pass just fine when in browser mode, but fail when in headless (e. g. sometimes dropdowns have issues or select Frame fails).
But unattended execution is no problem with UI.Vision. There are two different scenarios:
-
You use just Selenium IDE commands => Your screen can be locked
-
You use UI automation features such as XClick, XMove or XType . => Your screen can not be locked. In this case you have two options:
- Use Autologin (very easy, but depending on your use case, maybe not secure enough)
- Use an unlocked virtual machine inside your locked machine. This is a very secure option. I use UI.Vision inside Ubuntu 18.04 VMs that runs on a Windows Server Hosts.
However, I suspect that in order to do this, I will need to install the Chrome Kantu extension on this instance (as EC2 instances do not come with a GUI access and only ssh, I will first need to install a GUI), as well as the modules.
Exactly… but once that is done, I can confirm that UI.Vision works fine with Jenkins 