EnvJasmine - Test Your JavaScript Anywhere

Trevor Lalish-Menagh, http://trevmex.com

EnvJasmine is a test harness designed to allow you to test the JavaScript code in your project without the need of a web browser. EnvJasmine doesn’t care what language your application is written in nor which frameworks you use, it is designed to be completely self-contained. It is meant to be easy to drop into your application so your development team can perform automated front-end testing, catch more bugs and produce higher quality code.

Web Site: https://github.com/trevmex/EnvJasmine/
Version tested: 1.7.2
System requirements: Java 5 or greater
License & Pricing: Open Source, MIT License, Free
Support: Issues can be submitted at the issue section of the web site:
https://github.com/trevmex/EnvJasmine/issues.

Introduction

When we first wrote EnvJasmine in 2011, testing your JavaScript code was somewhat of a foreign concept in the world of enterprise web applications. JavaScript testing suites were few and far between. The only developers you could find using them were library maintainers [1] and radically novel consulting firms [2]. There were test suites like QUnit and Jasmine, but they were all designed to run within a browser. At the time I was working on a large Java web application that was being auto-run by our Hudson [3] continuous integration server every time someone checked code into our source control system. What I was looking for was a way to write JavaScript unit tests that would run on every check-in and "break the build" if a test failed, just like the Java developers had on the team. We also thought it would be important to make a tool that would be usable by not only Java web projects, but any project regardless of language or framework, and that is exactly what EnvJasmine delivers.

EnvJasmine is built off of two core technologies: EnvJS [4] - a headless browser written completely in JavaScript and Jasmine - a test framework inspired by RSpec [5]. With EnvJasmine, developers write JavaScript tests in Jasmine that are then loaded in the EnvJS headless browser instead of a normal web browser, decoupling your test environment from external resources. The results are produced as text with a proper exit status code (0 for passing, 1 for failure) to allow continuous integration servers to break the build.

Why "breaking the build" matters

To someone outside the industry, breaking something, especially a build, sounds like a horrendously bad thing. I would argue, though, that it is just the opposite. What I mean by breaking the build is having the continuous integration server fail when it encounters an error. That might seem fairly obvious, but it is astonishing how many projects today, especially in the enterprise space, do not have this ability whether due to lack of infrastructure, lack of planning or both.

The Java community has had this concept baked into it for years with test frameworks like JUnit [6] tying into auto-runners like Maven [7] that fail to compile if the tests do not pass. JavaScript, had been left in the dust until very recently. What EnvJasmine allows you to do is write tests in JavaScript for JavaScript that forces your project to fail to compile if the tests do not pass. This is a very good thing. Before the advent of EnvJasmine and other tools that came along later [8], even if you did write automated JavaScript tests they would have to be run by hand on a computer with a web browser. Most continuous integration servers are not set up to tie into a web browser [9] so oftentimes the tests would not be run at all. Pushing the JavaScript testing farther down the development lifecycle allows for more defects to be introduced into the code. When you break the build, it stops the defects from ever being released in the first place since the tests break at the earliest possible point (at code check-in). Early detection equals higher quality.

Getting Started

First, you will want to download EnvJasmine from our GitHub repository [10]. In your project’s test directory (if you do not have a test directory this would be a good time to create one, call it "tests") create a "javascripts" directory and unzip EnvJasmine there.

On the command line, run the following command from your newly created "tests/javascripts" directory: `bin/run_all_tests.sh` (on Mac or UNIX) or `bin\run_all_tests.bat` (on Windows). You should see the results of the sample tests pass on your screen. From here you can follow the section of the web site entitled "A Basic Tutorial" to get yourself up and running with writing EnvJasmine tests.

Your team will write the tests themselves in Jasmine. The Jasmine format is similar to RSpec and very easy to pick up. The Jasmine documentation page [11] is a great place to start for learning how to write Jasmine tests. EnvJasmine has Jasmine jQuery [12] and Jasmine AJAX [13] built into it to allow you to write test for your jQuery and AJAX JavaScript code. This means that if you are using jQuery, you can write tests that utilize special jQuery function and anonymous callback functions in AJAX calls will be testable as well.

Integration with Maven and Ruby on Rails

Because Maven and Ruby on Rails [14] are such common frameworks, we have created some example projects that integrate EnvJasmine into them. The Maven example [15] adds a plugin into your pom.xml file [16] that triggers all the tests to be run automatically whenever the test phase is executed. The Ruby on Rails example [17] adds a `test:javascript` rake [18] task in the lib/tasks/env_jasmine.rake file [19] that is executed whenever the test rake task is run. If you are using these tools, I encourage you to take a look at the example projects to get started.

Integration with SonarQube for Code Coverage

Code coverage tools allow you to have a visual representation of which lines of code you have written tests for and which lines still need tests. High code coverage helps your developers catch the parts of their code they forgot to test. EnvJasmine integrates with SonarQube [20] to give you code coverage statics on your project.

SonarQube is a fantastic tool for doing deep code analysis in your project. If you are fortunate enough to have this tool set up in your project, it is easy to integrate EnvJasmine into your SonarQube reports to see JavaScript code coverage. The instructions can be found on the EnvJasmine web site in the JSCover section [21].

Introducing JavaScript testing to your team

The technical hurdles of setting up EnvJasmine are small compared to the hurdles of changing your team to embrace a culture of testing. Having done this on a number of teams, I have found there are a few concerns that come up time and time again. As the change agent on your team advocating for JavaScript testing and breaking the build, you have to make sure you frame the experience in a positive light. You will get a lot of resistance to the idea, especially if your team is not used to developer-driven unit testing. Some of the common complaints are "writing tests will make it take longer to get things done," "I don’t have time to learn a new framework (Jasmine)" and "that is QA’s job." It is your job to answer these issues and stay positive. Let’s look at these three complaints a bit closer.

"Writing tests will make it take longer to get things done." Initially this is true. For the developer, it will take longer, but we have to consider the developer only one part of the project team. Automated tests mean less work for QA and less bugs being released to production. A developer spends more time fixing a bug that escaped to production than they do writing a test up-front. Writing tests in the long-term safe time in the future by catching defects that would otherwise be missed and have to be fixed later.

"I don’t have time to learn a new framework." There are couple of ways to approach this one: from the top and from the bottom. From the top, you can get management to buy into your idea that testing is good, therefore they should allow your team time to train on testing tools like Jasmine. This is ideal, since it will get the more reluctant among your development team motivated to test. From the bottom, you can study Jasmine yourself, give lunchtime training sessions to developers and make yourself available to field questions from your fellow developers when they are getting started. In truth, both these approaches in tandem make for a very successful testing adoption rate.

"That is QA’s job." This is an old traditional waterfall response to the idea that developers should write tests that still prevails in many enterprise settings. My main argument here is that the developer while writing their own code is the one person that knows there code the best, therefore is the best person to take (at least) a first pass at writing tests for the code. Automated testing using tools like EnvJasmine are not a replacement for a quality assurance team. QA engineers think about your product in a different way than developers, and that insight allows for more robust testing, but the developer, being closest to the code should be the one exercising the logic of the code to proof that it does what they expect it to do.

Contributing

Give EnvJasmine a try, and open up an issue on the GitHub repository for assistance. We are also very open to pull requests, so if there is something you want EnvJasmine to do for you that it doesn’t, we encourage you to contribute. It takes a village to make a great development tool.

JavaScript Testing Today

As I mentioned at the beginning of the article, in 2011 JavaScript testing was in its infancy. Today in 2014, testing your JavaScript code is a well-established norm among small and medium-sized web development companies, and is slowly making inroads in large enterprise teams around the world. EnvJasmine is a great tool for integrating JavaScript testing into an older system, a large enterprise system or a Greenfield project. In this time of hyper awareness on code quality, there is no reason not to ensure your JavaScript is well-tested and can break the build. With any luck, EnvJasmine can help get you there.

References

1. For example, jQuery’s QUnit (http://qunitjs.com) had been around for a while at this point.
2. Pivotal Labs, inventor of Jasmine (http://jasmine.github.io), which is used in EnvJasmine.
3. http://hudson-ci.org
4. http://www.envjs.com
5. http://www.methodsandtools.com/tools/rspecbestpractices.php
6. http://junit.org
7. https://maven.apache.org
8. Teaspoon (https://github.com/modeset/teaspoon) is a great one for Ruby on Rails projects, but it is not cross-language or cross-framework.
9. Although it is possible nowadays with tools like Selenium Grid (http://docs.seleniumhq.org).
10. https://github.com/trevmex/EnvJasmine/archive/master.zip
11. http://jasmine.github.io/1.3/introduction.html
12. https://github.com/velesin/jasmine-jquery
13. https://github.com/pivotal/jasmine-ajax
14. http://rubyonrails.org
15. https://github.com/trevmex/EnvJasmine-Maven-Example
16. https://github.com/trevmex/EnvJasmine-Maven-Example/blob/master/pom.xml
17. https://github.com/trevmex/EnvJasmine-Rails3-Example
18. http://rake.rubyforge.org
19. https://github.com/trevmex/EnvJasmine-Rails3-Example/blob/master/lib/tasks/env_jasmine.rake
20. http://www.sonarqube.org
21. https://github.com/trevmex/EnvJasmine/blob/master/lib/jscover/README.textile

---

More Software Testing Resources

• Software Testing Magazine
• Software Testing Tutorials and Videos

---

Click here to view the complete list of tools reviews

This article was originally published in the Summer 2014 issue of Methods & Tools