Choosing a JS Testing framework in XR — Part 1/3
JS Everywhere!
More than 95% of web-applications today use JavaScript as its client-side programming language. The introduction of NodeJS has brought about a revolution in server-based technology. It is the reason why more JavaScript-based frameworks are getting popular among the developer community — thanks to Google Chrome Team for open-sourcing V8 JavaScript engine!
By the principle of least power, JavaScript has become the de facto language of the web. Even in AR-VR space, JavaScript is gaining popularity and is widely used in segments like WebXR. The famous quote of Jeff Atwood — Co-founder of StackOverflow — about JavaScript back in 2007 is fast becoming a reality now:
“Any application that can be written in JavaScript, will eventually be written in JavaScript.” — Atwood’s Law
JS Testing Frameworks
According to stateofjs.com, amongst many JS testing frameworks available in the market, Jest, maintained by Facebook, is the most favorite among developers. With the rising popularity of ReactJS and other front-end frameworks like VueJS, preference for Jest has also gone up in recent times.
While the earliest testing frameworks have been around for more than a decade, few new ones have evolved by leveraging the earlier frameworks. Jest is built on top of the Jasmine framework with a focus on simplicity and so far has lived up to its expectations with the advent of zero-config based setup (work out of the box, config free).
Jasmine is a BDD styled, standalone, independent framework (need not even have a DOM) which is ideal for TDD. It has a clean, obvious syntax so that one may easily get started with writing tests. It is widely adopted as the testing framework in AngularJS and is usually the first choice to be used along with Karma (a command-line based spec runner tool for running Jasmine Specs aka tests in a production-like test environment). Jasmine also has a decent built-in assertion library (expect) and a mocking library (spy) out of the box.
Mocha is a significantly more flexible framework, but one has to piece it together — both mocking and assertion libraries are missing within the framework by default. As a mocking library, sinon.js (the ultimate spy library) is usually configured. Similarly, for the assertion, chai or expect.js is widely used. Thanks to its flexibility in using configurable assertion and mocking libraries, mocha is the most preferred JS test framework in the developer community.
Choosing a JS Test Framework
Recently I was developing a browser-based AR android application. It started as a simple URL based streaming application: but in due course, it had more feature requests coming in like Login, Screenshot, Recording, Pause/Resume & Start/Stop image stream, etc. Instead of using any front-end frameworks like ReactJS or VueJs, we used plain vanilla JavaScript — even no node based modules — as it served our purpose (we only had to invoke simple API end-points using AJAX).
The need of the hour was to set-up a JS testing framework to develop on the additional features. At the time, our team mostly consisted of Android and Unity developers and was fairly new to the ways of JS and its testing methodologies.
Jasmine, Jest, and Mocha were shortlisted initially — of which Jasmine was selected 👊 due to the following reasons:
- Since the team was fairly new to JS, we needed a framework which was easy to learn for beginners
- We also ensured that adequate documentation and examples were available online for reference.
- We wanted an easy to setup framework, with less moving parts (we preferred having both mocking and assertion libraries within the framework — out of the box by default).
- As we were using plain vanilla JS and not any front-end frameworks, we required a test framework that was standalone and could run the tests immediately — thus providing faster feedback for developers, to write and run tests during development.
- The tests had to be executed as part of our CI pipeline — with Bamboo as our CI and JFrog as the artifactory.
What we also learned during the development cycle is that, its:
- Good to have, if the JS tests can be run from IDE itself (this was going to be challenging, given that the IDE used in our project was Android Studio 😣).
- Better to have JS coverage reports generated too, as part of the CI.
Apart from all the above points, earlier familiarity with any of the given test frameworks also helps in choosing the right test framework.
After a short knowledge sharing session with our team on getting started with Jasmine, we found the framework quite easy and straightforward. There will be JavaScript experts from our AR-VR team soon 👊. Below is the screenshot of the JS test coverage on the completion of our project.
This is what “Developers call it Done”. 👏👏👏
Conclusion
There are several JS test frameworks available in the market. Choosing the right framework depends on a multitude of factors. For our project, we chose Jasmine as the JS test framework based on the requirements articulated above.
In the next part of the article, we will explain in-depth how to set up Jasmine as part of a project code-base, fundamentals on how to write specs, and lastly running them as part of CI, with test-coverage reports.
