Our team is planning to develop a framework to automate manual test cases. But we are stuck in choosing between javascript and java. With a bit of search, we found that Webdriverjs is the selenium bindings for javascript. Now, the main hurdle is whether we should go for javascript with webdriverjs or java with selenium-webdrier?
We already know java with selenium-webdriver but and as we are moving ahead for a new framework we just want to open easy, fast and more reliable option.
Please suggest javascript with webdriverjs(we need to learn javascript for this) or java with selenium-webdriver?
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
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)
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!
https://github.com/mekdev/mocha-selenium-pageobject
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With