javascript with webdriverjs or java with selenium-webdriver? [closed]
We ran into the same challenge that you are seeing now.There are a lot of selenium engineers on the Java stack but not much on the Node.js and selenium-webdriver stack.
Most newer modern testing frameworks are done in Node.js since both the front-end and back-end are done using NodeJS and will continue this trend. The question that I would ask is whether the development team is using Java (e.g. Tomcat) or are they using Node.js to develop their product. If they are using Node.js then it would be ideal to have the test framework written in the same language as well.
This is to facilitate
- Collaboration between development and automation team, locators and etc..
- Lessen the friction for developers to write selenium tests
There is a very good presentation on this by Marcel Erz at one of our South Bay Selenium meetups. I highly recommend you to go through it before making a decision.
Java vs. JavaScript (for UI testing)
- Most tests written by Front-end Engineers
- Unfamiliarity with Java and its eco-system
- Context switching
- Less likely to embrace testing
http://www.marcelerz.com/blog/talk-nodejs-based-selenium-testing-south-bay-selenium-meetup
Now if you are set on using Javascript the main challenge is of-course async-ness. Most automation engineers are used to sync patterns in Python and Java. It will take some time to get used to the async behavior of javascript. But the end result is worth it.
Our framework is mainly written in Node.js and we use Mocha as our harness and test runner. The recommended assertion library is Chai but you can use others if you need specific needs.
Our selenium library of choice is WebDriverJs (case sensitive) aka selenium-webdriver on npm which is the official JavaScript port. One of the main reasons that we went with selenium-webdriver is code readability and the ability to achieve sync-like syntax out of the box to keep Java test engineers in mind. This is achievable by leveraging the built-in Promise Manager control flows and Mocha Test Wrapper that automatically handles all the calls into the promise manager which makes the code very sync like.
https://code.google.com/p/selenium/wiki/WebDriverJs#Writing_Tests
Then it's a question of adding in your own framework and building the page objects. Page Objects in Javascript is a whole new beast you will have to get a good grasp of Prototypes and how you can emulate Java's inheritance.
You should also use selenium-standalone in npm as your only communication point to selenium for both local and remote execution instead of creating Driver instances (local/remote) in the test. This is so that the framework has the same interface and make things consistent. You don't want to keep track of multiple local driver executables and updating them. One package takes care of everything.
If you have read until here and you are pretty much certain that you will go with the Node.js route instead of Java. Below is a very simplified version of our framework that can help you get started. It has all of the implementations that was described above. Also any pull request is welcomed!
I'd personally choose selenium-webdriver package and instantiate the different drivers as needed. You're then not locked into just js driver.
Our team utilizes the selenium remote / grid for parallelization but in many instances we need a js driver.
Example in its:
WebDriver wd = new WebDriver()RemoteWebDriver rwd = new RemoteWebDriver()ChromeDriver cd = new ChromeDriver() // for chrome browserJavaScriptDriver jsd = .....