When it comes to unit testing, Java Script is still often treated as a retarded young brother of more “serious” languages. But the times of tiny snippets doing basic DHTML tricks are gone long and for good. Looking at a couple of sites I was working with recently, it’s hard to not realize how JS heavy they are. Front end code is often more complex than its server side counterpart (which is sometimes just a very thin wrapper over ORM layer). It is also no longer just “chrome” – nowadays JS powers many of app’s vital features.
It’s obvious you need to test it as thoroughly as the rest of your code base. But which framework should you choose? As there is a real abundance of Unit Testing tools for JS, I’ve decided to make my choice educated and carried out a research. This post presents a list of JS testing tools I’ve found and an overview of some important factors you should keep in mind when selecting one of them. In next installments of this short series I’ll continue with more detailed comparison of frameworks listed below.
xUnit style frameworks
- QUnit: http://docs.jquery.com/QUnit
- jqUnit: http://code.google.com/p/jqunit
- JsUnit: http://www.jsunit.net
- YUI Test: http://developer.yahoo.com/yui/yuitest
- JsTestDriver: http://code.google.com/p/js-test-driver
- JsUnit (berlios): http://jsunit.berlios.de
- JsUnitTest: http://jsunittest.com
- jsUnity: http://jsunity.com
- J3Unit: http://j3unit.sourceforge.net
BDD style frameworks
- Jspec: http://visionmedia.github.com/jspec
- JsSpec: http://jania.pe.kr/aw/moin.cgi/JSSpec
- Screw.Unit: http://github.com/nkallen/screw-unit
- Jasmine: http://github.com/pivotal/jasmine
- Inspec: http://github.com/aq1018/inspec
- jShoulda: http://jshoulda.scriptia.net
- SugarTest: http://sugartest.scriptia.net
Standalone mock frameworks
- JsMockito: http://jsmockito.org
- jqMock: http://code.google.com/p/jqmock
- JSMock: http://jsmock.sourceforge.net
- amok: http://code.google.com/p/amok
- Jack: http://boss.bekk.no/display/BOSS/Jack
- JJ: http://github.com/nakajima/jj
Mature, well documented and actively developed
I’m OK with using “edge” libraries in my app, as long as I keep it well covered with tests. But the testing platform itself must be rock solid. Staring for long minutes at a red bar, wondering if this is a bug in your class, your test code, in the framework, or just a bad API usage, although intellectually challenging, isn’t really anything funny. Good support and quick bug fixes for a tool you base the quality of your whole app upon won’t hurt either…
Support for different types of test runners
There are different scenarios for running Unit Tests: on a developer machine, from Continuous Integration server, inside an IDE. If you want to work really comfortably under all circumstances, your framework should support at least in-browser HTML runner, command line runner and an ability to aggregate results from running your tests automatically on several web browsers at once.
Built in mock framework
Java Script is a very open language. It’s not a problem to manually stub or mock a method in JS. However, restoring old method state after each test and verifying expectations by hand can quickly become burdensome. A robust mock framework, simplifying and automating such tasks, can spare you a lot of pain.
Although there are several standalone JS mock frameworks available, it is a nice bonus if such a framework is integrated into the testing framework, as it usually provides cleaner and more consistent syntax, thus enhancing readability of your tests. Another nice bonus, relieving you from a lot of ugly plumbing, is support for mocking AJAX requests and timers.
Built-in support for DOM manipulation testing
Typically, you interact with the DOM in your tests simply via framework of your choice (jQuery, Prototype etc.). But there are some features that make DOM manipulation testing a bit easier, e.g. built-in API for loading HTML fixtures or ability to automatically clean up DOM between tests.
BDD style syntax
Although the difference between two flavors of syntax – BDD and “classic” xUnit – may seem mostly a matter of taste, I think BDD style offers a couple of tangible benefits, especially nested contexts that allow for much cleaner organization of test code, resulting in improved maintainability. Together with natural language like matcher syntax and a more flexible test case naming (free text strings instead of method names) this has a positive impact on readability – which for tests is even more important than for a regular code.
I hope this brief overview will already help you get started with selecting your favorite framework. Look forward to further posts in this series for more detailed comparisons.