I want to run my Geb specs with chrome driver without having to watch the tests on the browser? can this be done?
P.D.: I know I can use the HtmlUnitDriver, but this driver sometimes gives my errors (caused mainly by timeouts) that the chrome driver don't.
There is currently no way to do this with Chrome, Safari, Opera or FireFox, however there are multiple options you can do. First is to pipe the "window" into a virtual frame buffer (if you're using Linux). This process will pop open the browser, only in memory. I talk about this in my blog post (http://www.ensor.cc/2011/05/maven-javascript-unit-test-using.html) during the maven pre-integration phase
The other option is to use the brand new GhostDriver. GhostDriver is a WebDriver implementation of PhantomJS which is a headless WebKit. This is WAY better than HtmlUnit but still has some features being built out. GhostDriver is currently not in Maven Central, so you will need to manually add it to the common repository. You can then use it as a WebDriver. This has worked for me with moderate success (90% of my test cases dropped in without any changes needed).
Read this first: http://blog.ivandemarino.me/2012/12/04/Finally-GhostDriver-1-0-0
Then refer to the GitHub README and code: https://github.com/detro/ghostdriver
Related
When I execute tests using MicrosoftWebDriver for Edge all works fine, but when I minimise the window all tests become failed. Does Edge or MicrosoftWebDriver have any options to avoid that behavior?
As you have been trying to minimise the Browser Window while your Test Execution is In Progress it will be against all the Best Practices. At this point it is worth to mention that as Selenium mocks the User Actions hence Selenium needs Browser focus. If the focus is lost Selenium won't be able to execute the lines of code. Consider the following steps while your Test Execution :
Browser Maximize : While you execute your tests always keep the Web Browser maximized so majority of the elements are within the Viewport
As per best practices, you should try to execute your Test Scripts / Automation Framework in an isolated Test Environment away from Manual Intervention with all the required Software and Hardware configurations and setup.
You can find a detailed discussion in How to run chrome driver in background using selenium with Ruby for Mac OSx?
You also have an option to use Google Chrome or Mozilla Firefox in Headless version.
For Firefox you can find a detailed discussion in How to make firefox headless programatically in Selenium with python?
For Chrome you can find a detailed discussion in selenium.common.exceptions.WebDriverException: Message: 'chromedriver' executable needs to be in PATH error with Headless Chrome
For Ghost Browser you can find a detailed discussion in Which drivers support “no-browser”/“headless” testing?
Sometimes, the browser window comes to the foreground and I'm clicking it accidentally which makes the test fails on some occasions. So, I just want to know, is there any way that I can keep the chrome driver window in the background.
Details:
< ChromeDriver version: 2.28.455517 >
< Chrome version: 58.0.3029.96 >
A few words about the solution to your Question:
As per best practices, you should try to execute your Test-scripts / Automation-framework in an isolated Test Environment with all the required Hardware and Software configurations and setup.
While the execution is in process, there should be no manual user interaction in-between.
In-case you want to do multitasking, use Ghost/Headless Browsers. You will find a detailed discussion in Which drivers support “no-browser”/“headless” testing?.
Htmlunitdriver & PhantomJS are the two mostly widely used Ghost/Headless Browsers.
If you are specific about using ChromeDriver you can use Chrome headless as per the documentation here.
First and foremost rule is that we should not do any other work while your scripts are running. We may use actions class for hovering., etc, while you move your cursor it may lead to failing your test case. Hope It will be useful to you.
You can try using headless switch available for Chrome.
This will run the automation in the headless mode and you will not be disturbed.
options = Selenium::WebDriver::Chrome::Options.new
options.add_argument('--headless')
Afterward, initiate Chrome.
Last weeks there has been a lot of noise about this new FirefoxDriver called Marionette. To use Firefox with Selenium, we used to use the "old" Selenium FirefoxDriver. From Firefox 48.0 onwards it is going to be required to use this new FirefoxDriver developed by Mozilla.
I understand it is required to change to that direction to get every browser supports and develops its drivers and to get drivers independent of Selenium. Besides, it is supposed if Mozilla develops its own driver, it will be faster and easier to fix issues and to develop features.
My question is, for those who create automated tests using Selenium framework, is there any benefit of using Marionette instead of the "old" Selenium supported FirefoxDriver? _(Such as a better performance, a better compatibility...)
The main advantage for using the Mozilla-provided, Marionette-based Geckodriver solution is that it works for versions of Firefox 48 and higher. The legacy driver provided and maintained by the Selenium project doesn't work for Firefox 48 or higher, and will never work for those versions of Firefox.
The legacy driver is implemented as a Firefox extension. This extension is installed in the profile used by the driver when WebDriver launches Firefox. Firefox 48 introduced two new features that disabled this browser extension. The first is the so-called "electrolysis" feature, or multiprocess Firefox. Electrolysis changes the way extensions have to deal with the browser in ways the Selenium team has not taken the time to fully understand.
The second, more important requirement is that all browser extensions must be signed by Mozilla before the browser will allow them to load. This latter feature has been in Firefox for several versions, but beginning with 48, it can no longer be disabled. The WebDriver browser extension introduces several valid security concerns for the Firefox browser, and as such, will not be signed by Mozilla's security team. This, in turn, renders the extension inoperable, and thus Selenium can no longer communicate with Firefox. The Marionette-based solution, being developed and maintained by Mozilla in the first place, is blessed by them for use in automating Firefox, and as such carries a commitment that it will continue to work with future versions moving forward.
So the primary benefit of using Marionette with Firefox 48 and higher is that it will work, whereas other solutions won't.
When you attempt to run Selenium tests in a scripting context whose origin is at "safari-extension://...", the session hangs. I believe the problem is caused by extension sandboxing, which means if I get Selenium running in the same origin as the extension I am testing, it should be possible to execute selenium commands in my extension.
Question: Can I incorporate the Safari Driver into my Safari extension during testing to circumvent sandboxing?
We modified the Safari driver to navigate extension:// pages, and the problem persists. It looks like Apple blocks Selenium at the extension level :(
I have recorded scripts through Selenium IDE and converted them to JUnit 4 Webdriver scripts.
Of course converted scripts had to be changed to run smoothly as Junits. Now my next goal is to make these scripts run on CI, So obviously I need some headless browser for this purpose. I found some threads, but I am looking for Junits specifically.
What could be the best solution/approach for this, any help in this regard is appreciated.
Take a look at PhantomJS. It is a headless WebKit-based browser and there is Selenium WebDriver for that called GhostDriver.
That's what i use and is OK but there is also the option of using a headed browser like Firefox or Chrome and then use Xvfb to ignore screen output.