Why should we use javascript for UI test automation?

Question

Background:JavaScript based automation frameworks heavily depends on asynchronous execution, promises, callbacks, anonymous functions, etc which are inherently complex and probably an overkill for a straight forward task like UI test automation where we identify objects based on some locators and perform operations.

Problem Statement: why should we choose JavaScript as a language for UI test automation considering it's fundamental asynchronous nature? What are the trade-offs of choosing it as a language for test automation?

Disclaimer: I have designed a couple of large automation frameworks using the protractor for multiple applications, but I want to understand the trade-off of choosing JavaScript as a language for UI test automation?

Note: I raised this question initially on Stack Overflow but as did not get much response so thought of this might be a better platform as focused on QA only.

Other Similar Questions: Also I have seen other close question(as remarked by Peter),but I think that question is based on the premise where we already have large test base in python/other language but I am taking one more step back where we even don't have any tests in any language.Should we even then consider JavaScript as a language for UI test automation in first place considering its inherent complexity and quirkiness for straight forward task like UI automation???

Answer 1

Yes - For Unit Testing Javascript

I've been working with this concept over the last few years and I've come to the following, multi-tier approach:

• Unit testing on the backend. For example with Ruby or Java on the server code.
• User acceptance testing on the UI using Selenium and a programming language such as Ruby with Capybara
• Unit testing on the front end with Jasmine, Konacha (Mocha/Chai), etc.

So I've most recently seen the javascript testing as that third item. It mocks and stubs the actual web page with a fixed fragment of HTML for the js to work against - this is what makes it a unit, not integrated or feature test. I was resistant to this initially ("but what about if the pages changes?") until I understood this classification and that the web page change scenario would be covered by the Selenium tests.

Jasmine: A behavior-driven development framework for testing JavaScript code. It does not depend on any other JavaScript frameworks. It does not require a DOM. And it has a clean, obvious syntax so that you can easily write tests.

Protractor: An end-to-end test framework for Angular and AngularJS applications. Protractor runs tests against your application running in a real browser, interacting with it as a user would.

Mocha: A feature-rich JavaScript test framework running on Node.js and in the browser, making asynchronous testing simple and fun.

Chai: Chai is a BDD / TDD assertion library for node and the browser that can be delightfully paired with any javascript testing framework.

QUnit: QUnit is a powerful, easy-to-use JavaScript unit testing framework. It's used by the jQuery, jQuery UI and jQuery Mobile projects and is capable of testing any generic JavaScript code, including itself!

Answer 2

We have recently started with writing WebDriver tests in JavaScript and I have to agree that the asynchronous execution is adding an unneeded complexity.

Pro's:

• Same test-runner as other (front-end) unit-tests
• Everyone knows JavaScript (e.g. front-end development with Angular, Vue or React)
• If you use JavaScript (e.g. NodeJS) also on the back-end, sticking to one language makes sense

Con's:

• Asynchronous execution complexity
• Hard to Google issues as most Selenium/WebDriver stuff is in Java (adding JavaScript barely helps)

We picked JavaScript because Java is a no go as our back-end is in C#. Also experience learned me not to add more programming-languages to the stack, certainly not any the developers had no experience with. C# WebDriver issues are just as hard to Google as JavaScript. Also I think C# bindings are not on par with Java and JavaScript as they get less commits on github.

JavaScript UI test frameworks:

It is possible to hide the Async complexity with JavaScript test frameworks like:

• CodeceptJS
• Nightmare
• Nightwatch.js
• Cypress (Cypress replaces Selenium completely)

For now we chosen to not research or use these frameworks mainly because one of our other teams decided to use plain selenium-webdriver for their tests.

With Nightwatch.JS I created a minimal test (with PageObject model) and it worked pretty well.

Some of these frameworks look promising and might be worth researching if you want to use JavaScript.

Answer 3

As you mention, the asynchronous chaining API seen in "selenium-webdriver" NPM package and also in nightwatch, protractor, testcafe, cypress, intern and wd.js etc can be quite hard to understand.

Luckily there is a way to write E2E tests in Node and still get an API that feels intuitive and synchronous, namely http://webdriver.io

Webdriver.io is able to do this because it uses coroutines from the node-fiber package to suspend execution until the async webdriver operation has completed.

I also wrote an in-depth comparison of Javascript E2E frameworks that covers exactly this aspect of E2E testing is JS. It also has a section that discusses why JavaScript E2E is a good idea vs writing testcases in Java.