Trevor Lalish-Menagh, http://trevmex.com
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:
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.
Integration with Maven and Ruby on Rails
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  to give you code coverage statics on your project.
"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.
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.
- For example, jQuery’s QUnit (http://qunitjs.com) had been around for a while at this point.
- Pivotal Labs, inventor of Jasmine (http://jasmine.github.io), which is used in EnvJasmine.
- Teaspoon (https://github.com/modeset/teaspoon) is a great one for Ruby on Rails projects, but it is not cross-language or cross-framework.
- Although it is possible nowadays with tools like Selenium Grid (http://docs.seleniumhq.org).
More Software Testing Resources