Software QA FYI - SQAFYI

Unit test JavaScript applications with Jasmine

By: Dustin Butler

For many, the idea of unit testing JavaScript applications seems difficult or unnecessary. Maybe the project does not seem big enough to warrant writing tests. Maybe the complexity of the application seems too difficult to write unit tests for. Problems arise with JavaScript scope, asynchronous XHR requests, DOM manipulation, and all the different browsers and platforms. Sometimes, JavaScript unit testing seems unreliable, brittle, or take more time and effort than it’s worth.

The good news is that dozens of JavaScript test frameworks, libraries, and test runners help solve the problems. These make implementing unit tests for your JavaScript applications quick, reliable, and easy to maintain. The bad news is, there are dozens of JavaScript frameworks, libraries, and test runners to choose from. Selecting a JavaScript test framework can be daunting.

In this article, I discuss some of the basics for writing JavaScript unit tests, some of the concepts behind test-driven development (TDD) and behavior-driven development (BDD). Then, you can apply that information to writing and running JavaScript unit tests with Jasmine.

What is Jasmine?
Jasmine is a behavior-driven development (BDD) JavaScript testing framework Pivotal Labs maintains it and makes it available on GitHub under the MIT license. Jasmine allows tests to be written independent of the DOM or other JavaScript frameworks. You run Jasmine in a browser, or headless without a browser by integrating with other frameworks such as Rhino, Envy, or the Jasmine-headless-webkit library.

Jasmine API includes features such as:
* A more natural BDD syntax for organizing the test logic than JUnit style assertion test frameworks
* Asynchronous testing
* Mocks
* Spies
* Easy to create custom matchers
* Ability to share or isolate behaviors between tests within a spec encapsulating parts of your spec.
* Continuous integration support

Many available libraries add additional functionality to the already robust Jasmine API. These include jasmine-ui, jasmine-features, and jasmine-jQuery for testing through the DOM, or Jasmine-species for changing the grammatical nature of the tests.

Jasmine is different from test frameworks like Selenium, which test the client application as a simulated user through the browser. It is similar to frameworks like QUnit, which programmatically test the JavaScript code directly. If you’ve written tests with other assertion frameworks, you will pick up Jasmine quickly.

Its syntax and test suite implementation are similar to Ruby’s RSpec framework, which takes a BDD approach to writing the tests. This syntax is different from the jUnit, QUnit, and FlexUnit style assertion frameworks that tend to verify the code from the inside out. Jasmine syntax is more narrative. It describes the behavior the code is supposed to support. It is written similar to the way an agile user story is written. And testing happens from the outside in. More on this later.

What kinds of tests should I use Jasmine for?
There are a variety of test types, for example smoke tests, integration tests, user acceptance tests, regression tests, and unit tests. Ideally, an application has a full testing story that includes all of these test types. Jasmine is not best suited to support them all. Jasmine is a unit testing framework, ideally suited to run unit tests and regression tests. Technically, you can use it to partially test integration between two systems. But, I do not recommend relying on Jasmine for 100% of your integration tests, because Jasmine only tests the Javascript code on one system at a time. Similar to integration tests, do not rely on Jasmine for 100% of your user acceptance testing. Tests are only as thorough as they are written. Acceptance testing is done, ideally, by business or end users.

What is a unit test?
At its core, a unit test is a program (known as a test case, or test specification) that isolates and tests a specific and small functional unit of source code. Never test too many pieces of code at one time. And, unlike with an integration test, do not use unit tests to test more than one system at a time.

Why write unit tests?
You probably already have an understanding of the value of unit testing your code. But if you are still skeptical, here are a few reasons that I hope convince you to write them.

* Unit tests demonstrate the code functions as designed.
* Unit tests can be run every time you compile your code or do a build. This consistency is especially useful when a developer checks in a change that inadvertently affects code in another area of the application.
* Running a suite of unit tests is faster than manual testing.
* Unlike manually testing your application by clicking through the fields in your browser, you are guaranteed that the tests run the same way every time. That is not to say that unit testing makes system testing in the browser unnecessary, but it does ensure a certain level of confidence in the code.
* Writing unit tests helps developers write better code. Whether you chose to write the unit tests before the code is written or after, the tests often persuade the developer to write code that is better structured, easier to maintain, and “composable” (in other words, modular and usually stateless).
* Unit tests provide documentation for the source code. These tests describe the interface to your code.
* Over time, you acquire a comprehensive suite of tests against the code base.
* Uncovering bugs before going to QA is cheaper.

Full article...

Other Resource

... to read more articles, visit

Unit test JavaScript applications with Jasmine