Driverless Automation With Selenium
- 08 Jul 2020 |
- 03 Mins read
Cypress is cool
I like cypress for automation - everybody does, right? It makes setting up things so smooth and implementing tests so frictionless, as if one has almost nothing to care about. I have made some experiments (and still do) with it in my GitHub repo cypress-baby-steps and also wrote a few lines about it in my last blog post. But what about Selenium? Note: this isn't another post on Cypress vs. Selenium, no, keep reading on. 😉
I also like Selenium. But the need there that one has to manually check and download the browser driver (binary artifact) for each type of browser separately, all the time, is just a real pain in the neck. 😩 The Selenium WebDriver API communicates with the specific browser-driver, which then natively drives the actual browser.
In order to locate these drivers, the absolute path of such a binary file has to/should be exported in a given environment variable (at least in Java) before creating a WebDriver instance:
Recently I asked myself: Isn’t there a better way of handling all these browser drivers? Automagically, without making my hands dirty? Good news, there is one!
The next generation of JUnit
JUnit is a unit testing framework for Java and was initially released in 2002 by Kent Beck and Erich Gamma. Did you know that it actually originated from sUnit? In 2017, another ground-braking milestone of JUnit was reached: JUnit 5 was released. I work now since 2 years with JUnit5 and I really like it. But why do I mention this here?
Less Driver Management = Selenium is cool (too)
Well, as I was searching for a Selenium JUnit 5 extension to get around the pain of organising the drivers by myself, I finally found Selenium-Jupiter 🥳 Once you include this dependency in your project, you simply need to specify the flavour of the browser driver you want to use in a test method and that’s it! No pain and (almost) no problems anymore 😅
But how does this actually work?
Selenium-Jupiter uses the dependency-injection extension model of JUnit 5 to inject the WebDriver objects into an annotated (
@Test) Test-Method. Further more, it does the following:
- It checks the version of the browser installed in your machine (e.g. Chrome, Firefox).
- It checks the version of the driver (e.g. chromedriver, geckodriver). If unknown, it uses the latest version of the driver.
- It downloads the WebDriver binary if it is not present on the WebDriverManager cache (~/.m2/repository/webdriver by default).
- It exports the proper WebDriver Java environment variables required by Selenium (not done when using WebDriverManager from the CLI or as a Server).
Thanks Boni García for creating and maintaining Selenium-Jupiter! A nice solution to avoid managing the painful boring stuff. It is a joy using it! 🙃
All in all, using Selenium with Java was never super easy before. But using it with JUnit 5 in combination with Selenium-Jupiter, is actually pretty cool!
Interesting readings about the vs.
- Cypress.io vs. Selenium Test Automation
- Puppeteer, Selenium, Playwright or Cypress?
- Cypress vs. Selenium WebDriver: Better or just different?
- Selenium vs. Cypress: Is WebDriver on its way out?
- Cypress vs. Selenium, is this the end of an era?
I think at the end of the day, it is not about which one is the better tool and which one you should never use again. Both of them are great and have its strength and flexibility for automation. In your project context, you and your team has to choose which one suites your needs best.
Thanks for reading Stay safe and happy! 💃🏽