We have ChromeDriverService class available in org.openqa.selenium.chrome ...
I understand this will help in starting the chrome driver on any port of the machine with the below code...
ChromeDriverService src = new ChromeDriverService.Builder().usingDriverExecutable(new File("Location of chromedriver.executable")).usingAnyFreePort().build();
src.start();
But not sure of how this is helpful for us in the automation, in which scenario this can be used ...
If we want to start the chrome browser with RemoteWebDriver having the DesiredCapability with Chrome, then we need to start running the selenium server standalone... the above ChromeDriverService is not useful there..
Please throw some light on ChromeDriverService
The purpose of ChromeDriverService is to manage a persistent instance of the ChromeDriver server.
Standard practice is to use the ChromeDriver class or the Selenium standalone server to obtain Chrome driver instances, but this practice sacrifices performance for convenience. In this scenario, each driver instance is associated with its own instance of the ChromeDriver server, which gets launched when the driver is requested and terminated when the driver exits. This per-instance server management adds overhead to test execution, both in terms of run-time and resource utilization.
Using ChromeDriverService, this overhead can be reduced to a minimum by enabling your test framework to launch a server instance at the start of the test suite and shut it down when the suite finishes. An example of this approach can be found on the ChromeDriver Getting started page under the heading Controlling ChromeDriver's lifetime.
Related
In using .net selenium webdrivers, I have been stumbling in 2 main issues, each for a different specific webdriver.
The table below shows the issues Chrome and Firefox webdrivers have been falling short with me:
I am using RellYa's selenium jquery extensions.
Chrome webdriver randomly throws a jQuery not found exception. If I try a couple of times, I eventually succeed.
With Firefox's webdriver, this never happened.
On the other hand, firefox throws a
Unable to bind to locking port 7054 within 45000 ms
Research shows that the reason behind this is that I must have left another firefox webdriver not closed/not quit. But this defeats my using selenium to automate web tasks, in a multi threaded manner. I mean, after a couple of threads are opened, seems it reaches some limit and waits for one of the opened webdrivers to close.
Actually, from this firefox webdriver's documentation, they make it clear that only one instance is supposed to be running. What one is supposed to do then if he had in mind multi threading ?
Does any one have working solutions for the problems singled out in the table, for each specific webdriver implementations ?
No, you can run multiple instances of firefox, chrome, or whatever from your machine at any one time. If you research "Selenium Grid", you will see that it is designed to do that.
So:
The unable to bind message on firefox is not caused by another driver locking a port. Each driver instance starts on its own open port.
If you are not using Selenium Grid, or not using the grid, and are trying to handle the multi-threading yourself, just be careful of how you open and close your browsers in your #Configuration phases in your test runner.
As a educated guess, if you have instability, its more likely because you are trying to control a newer browser with a too-old version of Selenium? We need more info on your question, such as an example project to look at.
I'm using protractor for testing. 99% of the times there's no need to actually see the browser, the tests take a long time, and all we're interested in is the final outcome.
Is there a way to hide the browser opened for testing (e.g. run in the background)?
As stated before, docker-selenium works wonders. The only browser not supported by docker-selenium is Internet Explorer, for obvious reasons.
From what I understand, you cannot really reliably control the way browser windows are opened via protractor/webdriverjs/selenium.
A common way to approach the problem is to use a virtual display, see:
Can Selenium Webdriver open browser windows silently in background?
An alternative way to accomplish that, would be to run tests inside a docker-selenium container, here is a quite detailed introduction:
protractor with any headless browser?
Or, as pointed out here and if you are on Mac OS X, you can run selenium tests on the same machine but under a different user which would not interfere with your current display.
You can also run protractor tests in a docker container in a headless firefox:
Protractor-Firefox-Headless-Docker
Another alternative would be to use a remote selenium server, as, for example, BrowserStack or Sauce Labs services provide.
You can try headless browser like PhantomJS for this purpose. PhantomJS runs in background and failures can be captured using screenshot.
Refer following link to know more about phantomjs:
Protractor running tests on PhantomJS
I have two machines, one with all the stuff I need (Eclipse + TestNG +scripts) and the other one with just browsers installed.
I use Selenium Grid 2.35.0.
Everything seems to be fine except the problem that very often I get this error:
Error communicating with the remote browser. It may have died.
Scripts are not complicated at all, I run them one-by-one, so it just happens randomly. I don't think it's because of the browser.
Any idea/fix?
If you need more info I'm here.
The only time I get that error is when I manually close the browser myself. I would verify that the machine withe the browsers is stable.
It could also be due to calling driver.quit() and not instantiating another driver (I haven't ever done this, so I don't know what error this throws)
I notice this error as well but ONLY when using Selenium grid (using 2.35 but 2.38 exists now)
When I run locally I don't get error communicating with the browse but typically it can happen when there is a bug with your setup and teardown code (maybe one of your classes creates an instance of your browser before your setup function gets called)
See How to close child browser window in Selenium WebDriver using Java
ensure to call driver.close(); on every popup / new windows / new tab you open during the test (after switching to it using driver.switchTo())
and to call driver.quit(); at the end of the session (generally in #AfterClass annotated method)
I have written my RF testcases using reusable keywords (built using native selenium webdriver not using Selenium2Library) and It works fine on single instance for what so ever browser I run.
But, I would like to execute these testcases in parallel on
1) Same machine different browsers
2) Different machine all browsers
Does Selenium Grid have native support to Robot Framework test cases? Or have any body found an alternative?
Yes, Robot Framework has native support for Java and Selenium2 within your defined "keyword" code blocks. All you do is use RemoteWebDriver in your keyword phrases instead of using WebDriver . This requires you run a Hub and a Node for the RemoteWebDriver to refer to, of course, or you can use a Sauce Labs account. Using Grid and Node you can run parallel tests with very little effort.
If you don't want to use RemoteWebDriver, you can still use WebDriver locally but you need to run parallel tests using "Maven surefire with threads" or a Gradle task with --parallel-threads=3" option. I have examples of this that you can see in my GitHub account.
We just deployed selenium server 2.0b3 (upgraded from 1.0.3). It
looks like there are some fairly serious memory leaks - OutOfMemory
exception thrown during runs longer than 30 minutes long.
Is there any straight forward workaround for dealing with the memory leaks in the
2.0b3 selenium server?
I was hoping to get the 2.0b3 source, apply the assorted patches
submitted thus far and use this. However, when I pull this:
svn checkout http://selenium.googlecode.com/svn/tags/selenium-2.0-beta-3/
selenium-2.0-beta-3
and build with
./go clean release
The resulting binaries don't appear to have the
DefaultSelenium.class. Not sure what is going on here...
Alternately, I thought maybe we will just start working with the
latest release candidate. However, looks like the
DefaultSelenium.class is not here either.
Do I need to upgrade the client code to use WebDriver? I thought
things were suppose to be backwards compatible.
Suggestions?
for backwards compatibility you should use the WebdriverBackedSelenium like this:
FirefoxDriver driver = new FirefoxDriver(); //or any of the other drivertypes
Selenium selenium = new WebDriverBackedSelenium(driver, START_URL);
Specifically what kind of OutOfMemoryException is getting thrown? Heap? GC overhead limit? other?
I was getting "GC overhead limit exceeded" and sometimes also "out of heap space" as the message within the Exception (both 1.0.3 and 2.0.b3, using ruby selenium-client-1.2.18), and found your thread on the selenium-developers google group.[1] Have you followed along with the responses there?
Turning logging off for selenium-server (both -log AND -browserSideLog) stopped the OOMEs for me. I can wait till the next selenium-server release to get Kristian's patches.[2]
[1] http://groups.google.com/group/selenium-developers/browse_thread/thread/30d38475a16985a9/0db1af2456304f9f?hl=en&lnk=gst&q=outofmemory#0db1af2456304f9f
[2] http://code.google.com/p/selenium/source/detail?r=11872