Apologies, I'm still fairly new to selenium so please bear with me as I explain this.
Currently my selenium tests are running on a remote machine but no window opens when I'm remotely logged into that machine!
My setup is:
Remote machine has 2 admin users with Selenium Grid2 and a node as a windows service.
The machine is running windows server 2012 with the services having Interactive services enabled.
I am using Selenium 2.42.1 with IEDriver version 2.42.0
Tests are being built and run remotely on our build server.
I think that's everything, if there's any more information then please let me know as I'd really like to know why I cannot view my tests running.
Just for clarification, the tests are running and they successfully pass or fail where necessary, but I just can't see it if I'm remote logged into the machine.
UPDATE
There has been some interesting progress on this issue but still no resolution.
I decided to try and run a node from command line and funny enough the tests run with no problems and the browser window is displayed.
So if anyone has any idea why a browser window would appear when running a node from command line but not when running a node as a service would be great.
I'm using java service wrapper to create my service and im using the same nodeconfig.json when running the node.
This can happen when you are running the node as a windows service. There is an option in service to say whether the job should run in background or interact with desktop. Check that and you should see the windows.
Related
I am running an Azure Pipelines (DevOps) pipeline that builds my automation test solution into a dll, and loads that dll to get all of the integration automation tests.
I am using the default cloud "Host" agents to run the automation. However, the drivers throw tons of errors. I recognize the errors as the same ones that I encountered when I set up automation via Jenkins -- when I was running Jenkins as a service.
To fix the issue in Jenkins, I stopped running it as a Windows service, and started launching it as a java -jar Jenkins.war command in Powershell. That allowed the selenium drivers to launch browsers as normal on the VM's desktop, rather than running the browser instances and drivers completely in memory.
So, when it ran the browser windows and drivers completely in memory, I received the same driver errors as I am now encounting on the Host agents in Azure Pipelines. The problem is that I cannot find how to make the Agents run the tests on the VM desktop. I don't have any idea where to start on solving this problem, and can't seem to find any info online about this.
Edit: To be as clear as possible. The ONLY error occurring is "$ is not defined". This is because the DOM does not load properly because the browser executables and driver executables are running completely in memory, headless. I need to be able to run the executables in a rendered part of the host machines. So, what I mean is, if I were to remote desktop into this machine, I would actively see browser windows rendering, and automation running. Right now though, if I were to remote into this VM, I would see chrome.exe, and chromedriver.exe in TaskManager, but nothing would be visible on the desktop.
I found the answer.
https://learn.microsoft.com/en-us/azure/devops/pipelines/test/ui-testing-considerations?view=vsts&tabs=mstest#visible-ui-mode
You must manually configure the hosts to run Selenium non-headless. This will prevent everything from running as a service, which is purely in memory, with no UI components. This is the problem I mentioned that Jenkins encountered when running Jenkins as a service.
The fix for Jenkins running automation with a GUI is the same for the Hosted agents in Azure pipelines, ultimately. It's just a manual configuration. This is done via a plugin and build step in pipelines.
So that we may perform front-to-back web UI testing, we are using Selenium and ChromeDriver to automate page loads/interaction as part of our testing pack.
This is behaving as expected during developer testing (on a developer's local machine), but we are struggling to perform these checks as part of our continuous integration build.
Our server plant is *NIX based, and all of our CI infrastructure runs on these machines. So that we may test Chrome under Windows (our delivery mechanism), we have configured a Selenium Grid. When the CI tests run, they access the grid, in order to locate a Windows node to run the tests on.
We have had a Windows desktop provisioned solely for the purpose of running these tests. This contains our standard enterprise build of Windows 7. This machine will be periodically rebooted in-line with the IT department's update policy.
In an effort to ensure the Selenium server is always running, we have added the Selenium Server (running in "node" mode) as a Windows service. The selenium Server is configured to start-up ChromeDriver to invoke the simulated user-interaction.
However, when running the tests from CI they fail due to timeout. Our working theory is, the system user that is running the service cannot create interactive windows. A web search has raised reference to the "Session 0" problem, but with little to no constructive advice on how to move forward.
Starting the Selenium Server process manually from an interactive session is not a viable solution, as this is leading to brittle tests - which are failing due to an infrastructure problem, rather than a genuine test regression.
How can we have an instance of Selenium Server started via a Windows Service whenever the system reboots, that is capable of launching Chrome instances?
It could be easily done with NSSM.
Installation of services looks like these:
nssm install seleniumhub java -jar C:\selenium\selenium-server-standalone-2.45.0.jar -role hub -hubConfig C:\selenium\hub.json
nssm install seleniumnode java -jar C:\selenium\selenium-server-standalone-2.45.0.jar -role node -nodeConfig C:\selenium\node.json
It provides easily way to remove service if needed:
nssm remove seleniumnode confirm
Add destination to nssm to your PATH variable and run from console as admin
UPDATE April 2021
NSSM is not supported for more than 3 years. So please consider other options like winsw or any other. WinSW does the same job as NSSM and allows to keep run configuration in xml.
You cannot run Selenium Grid as a windows service ever since Windows Vista. Microsoft calls it "Session 0 Isolation". You could do it in Windows 2000 or XP but since the time that Vista came out, Microsoft no longer will let Grid interact with the desktop (or any other UI programs for that matter). Regardless of the fact that you still see that "interact with desktop" checkbox, it is a red herring. So, you MUST run Selenium Grid in the foreground on that server in order for it to get access to the session. If it is running Windows Server, you could in theory have multiple sessions and leave Grid running in the foreground on one of the non-zero user sessions.
Right now you can't help it - it used to work fine in session 0 but for the past few days after chrome update only works for interactive sessions.
Related bugs:
https://code.google.com/p/selenium/issues/detail?id=8029
https://code.google.com/p/chromium/issues/detail?id=422218
My preferred solution to this problem (and my default choice for running Selenium Grid as a service) is to use a simple tool called AlwaysUp. It has a free 30 day trial to try it out.
What to do:
Download AlwaysUp
Configure AlwaysUp to start the Selenium Grid node on startup
Configure AlwaysUp to run the Selenium node as a specific user (not the default System user)
This way the the node will run as a service, survive machine restarts and work with the latest version Chrome.
If the user account you use to login to the machine is different from the user account you specify to run the node as a service then you will not see the browsers pop up on the desktop as they are running in a different user session. The end result is that it is almost identical to running as a normal service but gets round the Session 0 issue.
Yeah, you should use NSSM. Important is, that you add your windows account in the "Log on" tab, or any other valid account. If you run your node with the "Local System account" option, you will get the session 0 problem. With a normal user session, the nodes run smoothly invisible in the background :)
we don't use selenium GRID, we were disappointed with its stability. We use a "Jenkins Grid", that is jenkins slaves nodes on various servers.
The slaves are services with the interact with desktop flag. They run as services with NSSM, and the SERVICE_INTERACTIVE_PROCESS flag. Making sure that NoInteractiveProcess is set to 1 (cf https://learn.microsoft.com/en-us/windows/desktop/services/interactive-services).
We don't have the fancy features of the grid (that is balancing according the browser types slots). Instead, we have Jenkins balancing the test jobs using a slave node or another.
Initially we did not use the interact with desktop flag, having browsers to run without "real" display, but the behavior was not very stable (especially with resize commands).
Hope this helps.
As I explained on this thread, I found that using a small paid tool FireDaemon Pro saved me a lot of time from trying to configure NSSM and other free tools.
It works well in the background, and restarts Selenium along with the server, which was my main requirement for running Selenium Standalone Server as a Windows Service.
This free tool would probably do it:
http://yajsw.sourceforge.net/
For that to work, you need a wrapper.conf file and a script to run the YAJSW wrapper. I takes time to read the documentation, but it is a free solution.
I wrote an example shared here, that installs JBoss7 as a Windows service.
Of course, you can simplify my example by a lot.
I'm trying to automate some selenium tests.
I can run them locally in my machine, but when I try to run them in windows server 2008 (the server in which our CI server runs) the Firefox window only opens if I open the cmd line with admin privileges. I don't wan't this to run with admin privileges, so the question is: what do I need to do to be able to open Firefox window with a regular user?
There is nothing you can do about that. Starting with Windows Vista, Microsoft locked down the "interactable" sessions and so running WebDriver grid hub as a service which starts browsers in a desktop session will not work unless you are using Windows XP. So, what you need to do is have multiple grid nodes running in the foreground and leave those desktop sessions open in Windows 2008. Also, with Jenkins, running Selenium tests (without a grid) will exhibit the same problem where you'd have to run Jenkins in the foreground.
Windows says "By default, services use a noninteractive window station and cannot interact with the user. However, an interactive service can display a user interface and receive user input.". Also, "All services run in Terminal Services session 0. Therefore, if an interactive service displays a user interface, it is visible only to the user who connected to session 0. " See this site for this info.
The holy grail would be to write a Java program using SystemTray and then have the tray application auto-start a grid node session in the foreground when a desktop session starts. Just an idea since VisGrid cannot do this.
On Linux, there is a way to use xvfb to run grid as a service and run browsers in a headless session, but its a complex setup I think and I have never tried it. It's not very much different that the Windows situation anyway and I think the windows setup is easier.
I configured Jenkins as Selenium Grid and some Jenkins Nodes as Selenium Nodes (controlled by Jenkins Selenium plugin).
The nodes are connected with the option "Let Jenkins control this Windows Slave as Windows Service".
The service is defined automatically at the node as "interact with desktop".
Jenkins slave enables Selenium remote driver service
The problem is that the resolution of UI tests is really low (1036 x 780) where we need (1600x1200).
Opening an RDP session doesn't help since the service was started by Jenkins.
How to change the default resolution of windows service that can interact with Desktop?
I had the same problem as yours. Difference was I also have GUI automation besides Selenium tests. I ended up installing VNC service on all the nodes and wrote a script to change the desktop resolution before running any tests. However the highest resolution by doing that we got is 1280x1024, which resolved my problem.
If you don't mind giving up running Jenkins Slave as Windows Service you can use this way:
Jenkins on Windows and GUI Tests without RDC
Still - that would make you maintain an open RDP session that runs Jenkins JNLP process... So that solution is working, but not very optimal.
The issue is that Sikuli's image recognition capabilities only work when the target of the Sikuli tests is in the foreground and it has full access to the mouse. In its current configuration, Jenkins projects are never visible from the desktop of the windows slave node.
The way my current automated testing suite is setup right now, about 30 tests are written using only selenium. In the final two tests, selenium starts a webdriver (currently chromedriver but can be firefox or IE) and navigates to the right pages and Sikuli does its thing from there. Both use the java language bindings.
Currently Sikuli appears to be installed correctly, but when it is asked to click through a list of screenRegions supposedly populated by matching the desktop with a target image, it immediately throws a NPE.
How do I change my Jenkins setup on my windows 7 slave to allow the browser to be launched in the foreground, as it is when i run it from my windows 7 development machine?
So you've got a development machine where Sikuli works, and a test machine where Jenkins runs Sikuli and it doesn't work.
I had this same setup (with the Sikuli tester/Jenkins slave running Windows 7). What worked for me was to have the test machine run a VNC server, log in as a the tester account over VNC, and launch the Jenkins slave as a regular application and not a service. I used UltraVNC server.
As far as I could tell, the problem stems from Windows' security measures, which are designed to prevent a remote user from controlling your machine without your presence.
If you run Jenkins as a service, it doesn't get a real desktop allocated to it. The script will run, but (as you're seeing) Sikuli won't actually be able to find anything because there's nothing for it to look at. (Selenium is inspecting the page content programmatically, so it doesn't mind that the page is not actually displayed on any screen.)
You can also just run Jenkins and leave yourself logged in, and skip the VNC server. I wanted to run the machine without a monitor or keyboard and still have control, though. If that's your goal as well, you can't use Remote Desktop, because it allocates a new desktop on connection and then destroys it when you disconnect. (So Jenkins will work when you're watching and fail when you leave for the night. Very frustrating!)
As a side benefit, if you do it this way you can connect over VNC and watch Jenkins as it's running the test.
make the slave machine remote desktop to itself.
run the jenkins salve as program in that session
cmd /c start java -jar slave.jar -jnlpUrl http....slave-agent.jnlp -secret ... (find it in your jenkins master (shown when the slave service is down)
set it all to run at salve win startup.