I am running coded UI tests using Selenium from a build in VSTS.
The test library is built on a test agent (hosted and private available) and copied to a VM running Windows 10. Then the test agent is deployed to the VM and the task 'Run Functional Tests' is executed. The tests to be executed are selected through an association in the test manager of VSTS.
I would like to run these UI tests (in Chrome) in different screen resolutions, but when the test agent is executed, the headless session always runs in the default resolution of 1024x768. I need to run tests up to a 4k resolution. If there is a current session with the same credentials in a higher resolution, this session is "hijacked" and the tests run in the desired resolution.
But I cannot guarantee an existing session when those builds are triggers by either a schedule or another event.
I already followed an MSDN article how to specify a default resolution in the registry, but that doesn't work on neither Win10 nor on Srv2012.
Is there a parameter/setting in a test/run setting file that specifies the resolution of this headless session?
To avoid confusion: I know how to set the windows size of the browser, but that is limited to the maximum screen resolution, so the Selenium-specific commands to resize the browser don't do the trick ;)
Any hint appreciated! Thanks!
Related
I have about 130 Selenium UI tests for a web app we're currently developing.
The problem I have is, whenever I run the tests locally through Visual Studio's test explorer (vstest), I have never encountered this error before.
The problem is, some of the tests keep failing due to this message when the tests are run on TFS (using vstest on TFS too). element click intercepted
I'm also 100% sure there is no overlaying element that interferes with the click method as the tests never fail with that message when run locally.
Any idea what could this be?
I had issues where all of my local tests would pass, but I would receive random errors as you mentioned when running the tests through Jenkins or TFS, usually errors indicating that my elements were not clickable, etc. - the issue ended up being the browser size.
I started running my test in headless mode and specified a large browser size. Switching to --headless and setting a browser size ended up solving most of my issues for me:
var headlessOptions = new ChromeOptions();
headlessOptions.AddArgument("--headless");
headlessOptions.AddArguments("--disable-gpu");
headlessOptions.AddArguments("--window-size=1920,1200");
You will have to use --headless for this to work too. I tried to run my tests by ONLY setting window size, but the tests would still fail anyway because the resolution of the virtual machines was not large enough to handle the browser size I had set.
You can resolve this issue by using 2 methods.
1.Running chrome in headless mode
2.Scorlling to the element before clicking or interacting with it
The root cause of this issue is due to the fact that the browser does not load with a browser size as that of browser when tested locally
If you intend to run the test in non headless mode you can use the following code to achieve the result.
IWebElement element= driver.FindElement(By.Id(selector));
((IJavaScriptExecutor)driver).ExecuteScript("arguments[0].scrollIntoView(true);", element);
Could someone please help me understand the difference between the remote control server in Selenium Grid 1 and the remote control server in Selenium Grid 2. From what I've read, one of the main differences between the versions is that version 2 of Selenium Grid was merged with Selenium Remote Control. Is this the same remote control as Selenium 1, that was responsible for proxy injection? as I thought this had been deprecated.
This is as of Selenium 3.4.0
We now have two separate artifacts.
For example if you head down to the Selenium downloads URL you would notice the following two artifacts
selenium-server-standalone-3.4.0.jar - This is the Grid (or Grid2 as you call it) as we know. This standalone jar can work in 3 modes viz.,
Hub - It acts as the hub standing in between your test and the actual node that gets the work done. Kind of like a postman/mailman and a match maker.
Node - This is the actual place where all the action happens. When running in this mode, it is responsible for getting automation requests from the tests routed via the Hub and opens up browsers, performs UI actions etc.,
Standalone - This is pretty much the same as Node but just that it doesn't require a Hub to route the automation test traffic to it. Tests can directly point at the Standalone and then start running. I believe this is perhaps the kind of setup that third party execution environment providers such as SauceLabs maybe using. (This is just a hunch, I don't know for sure).
selenium-html-runner-3.4.0.jar - This is where all the legacy stuff (or Selenium RC as you call it) has moved into. So if you had a html test suite that you created by recording a UI flow using Selenium IDE and wanted to run them from a command line (Note that you can always execute a html test suite from within the Selenium IDE and don't need anything extra), you would use this.
There is nothing called as Selenium Grid1 anymore. There's only Selenium Grid2 (which is the re-engineered version of Grid1).
The Selenium RC support exists only as a stop gap solution with no maintenance as part of selenium-html-runner-3.4.0.jar. This has been officially deprecated and there's no support for issues that surface on this.
The expectation is that if one were to be using Selenium and building new tests, then one should be directly using only the WebDriver APIs (which is Selenium2) and not fall back to using DefaultSelenium APIs (which is Selenium1)
Hope that helps!
I put together a machine (Windows Server 2012R2) for POC reasons where a Jenkins installed and it executes Selenium UI tests using msunit
But, when I log in the server where the Jenkins runs and I watch what happens during CI build (compile and test execution) I can't see that the browser (Firefox) starts automatically, however, the test results and the logs show that a browser was executed.
My question is that, what the is happening when my tests are executed by Jenkins? If I execute the command which from visual studio on the same machine then I can see that Firefox starts, does what is programmed in the tests and the results are in the result.trx.Can I somehow set up Jenkins the way the browser really executed (I can believe it when I see it :)
In Jenkins when you run selenium test cases, they are executed in the background by default.
Your Jenkins might be configured to run those test cases in some video buffer(usually it happens on Linux but can also be configured on Windows) or in a headless state.
As your question, if you are using MSTest which basically used to convert the test cases result from trx to JMX format but also can be used to run selenium tests. when you run the same in Jenkins it will run in background on any slave or on master.
I'm using selenium and phantomjs to run automated tests. My tests run fine on my local machine. I need to run my tests on a windows server as part of a scheduled task that then emails the results each morning. When my tests are run on the server, a good majority fail and the screenshot that is taken upon failure is blank. Logs show it would appear its failing to load some pages when navigating from one page to another.
I am trying to get Hudson to run my ruby based selenium tests. I have installed the Selenium Grid plugin, but I don't want to have the RC's running as slaves in a Hudson cluster. The reason for this is I don't want to waste the next six years of my life trying to configure each of my projects in various Windows environments.
Hudson currently pulls each project from Github and builds it just fine. With a regular Selenium Grid setup, I am able to edit the grid_configuration.yml file to represent the various environments I wish to tests against, then pass environment variables to the rake task that runs the test i.e. which browser/platfom to run on and the URL of the application under test -- usually a port on the hub machine running in a specific environment.
In this way, the machines on which the RC's run don't need to know anything about the source code of my apps, they just need to have selenium-grid installed and have registered with the hub.
Is there a way of elegantly emulating this with Hudson?
do you have a concept of build agents, I do not know much about Hudson. We are using Anthill Pro at work and we have set up an Ahtill Pro agent. The source code is downloaded to the agent and the agent is responsible to run the maven goal for running the tests. It works pretty well for us as the RC machines are not part of the build environment. the tests are responsible to talk to Selenium HUB and get new sessions and do the testing.
I hope this helps.
Cheers
Haroon
I chose to not use the plugin in order to take advantage of the newer Grid version. I cloned a few VMs with a startup script that runs ant launch-remote-control from a shared drive that they can all access. Hudson doesn't have, and doesn't need any access to the Grid nodes and they aren't slaves to Hudson. I altered my Hudson server to launch the hub on machine startup. This setup allows me to run the grid normally with or without Hudson.