Jasmine JavaScript Testing

There are many complications when dealing with client JavaScript code; the obvious one, is that you cannot control the client's runtime. While on the server, you can run a specific version of your Node.js server, you can't oblige your clients to run the latest version of Chrome or Firefox.

The JavaScript language is defined by the ECMAScript specification; therefore, each browser can have its own implementation of a runtime, which means there could be small differences or bugs between them.

Besides that, you have issues with the language itself. Brendan Eich developed JavaScript in just 10 days, under a lot of management pressure at Netscape. Although it got itself right in its simplicity, first-class functions, and object prototypes, it also introduced some problems with the attempt to make the language malleable and allow it to evolve.

Every JavaScript object is mutable; this means that there is nothing you can do to prevent a module from overwriting pieces of other modules. The following code illustrates how simple it is to overwrite the global console.log function:

console.log('test');
>> 'test'
console.log = 'break';
console.log('test');
>> TypeError: Property 'log' of object #<Console> is not a function

This was a conscious decision on the language design; it allows developers to tinker and add missing functionality to the language. But given such power, it is relatively easy to make a mistake.

Version 5 of the ECMA specification introduced the Object.seal function, which prevents further changes on any object once called. But its current support is not widespread; Internet Explorer, for example, only implemented it on its version 9.

Another problem, is with how JavaScript deals with type. In other languages, an expression like '1' + 1 would probably raise an error; in JavaScript, due to some non-intuitive type coercion rules, the aforementioned code results in '11'. But the main problem is in its inconsistency; on multiplication, a string is converted into a number, so '3' * 4, is actually 12.

This can lead to some hard-to-find problems on big expressions. Suppose you have some data coming from a server, and although you are expecting numbers, one value came as a string:

var a = 1, b = '2', c = 3, d = 4;
var result = a + b + c * d;

The resulting value of the preceding example is '1212', a string.

These are just two common problems faced by developers. Throughout the book, you are going to apply best practices and write tests to guarantee that you don't fall into these, and other, pitfalls.

Jasmine is a little behavior-driven development (BDD) test framework created by the developers at Pivotal Labs, to allow you to write automated JavaScript unit tests.

But before we can go any further, first we need to get some fundamentals right, starting with what a test unit is.

A test unit is a piece of code that tests a functionality unit of the application code. But sometimes, it can be tricky to understand what a functionality unit can be, so for that reason, Dan North came up with a solution in the form of BDD, which is a rethink of test-driven development (TDD).

In traditional unit testing practice, the developer is left with loose guidelines on how to start the process of testing, what to test, how big a test should be, or even how to call a test.

To fix these problems, Dan took the concept of user stories from the standard agile construct, as a model on how to write tests.

For example, a music player application could have an acceptance criterion such as:

Given a player, when the song has been paused, then it should indicate that the song is currently paused.

As shown in the following list, this acceptance criterion is written following an underlying pattern:

In Jasmine, this translates into a very expressive language that allows tests to be written in a way that reflects actual business values. The preceding acceptance criterion written as a Jasmine test unit would be as follows:

describe("Player", function() {
  describe("when song has been paused", function() {
    it("should indicate that the song is paused", function() {

    });
  });
});

You can see how the criterion translates well into the Jasmine syntax. In the next chapter, we will get into the details of how these functions work.

With Jasmine, as with other BDD frameworks, each acceptance criterion directly translates to a test unit. For that reason, each test unit is usually called a spec, short for specification. During the course of this book, we will be using this terminology.

Getting started with Jasmine is actually pretty simple.

Open the Jasmine website at http://jasmine.github.io/2.1/introduction.html#section-Downloads and download the Standalone Release (version 2.1.3 is going to be used in the book).

While at the Jasmine website, you might notice that it is actually a live page executing the specs contained in it. This is made possible by the simplicity of the Jasmine framework, allowing it to be executed in the most diverse environments.

After you've downloaded the distribution and uncompressed it, you can open the SpecRunner.html file on your browser. It will show the results of a sample test suite (including the acceptance criterion we showed you earlier):

This shows the SpecRunner.html file opened on the browser

This SpecRunner.html file is a Jasmine browser spec runner. It is a simple HTML file that references the Jasmine code, the source files, and the test files. For convention purposes, we are going to refer to this file simply as runner.

You can see how simple it is by opening it on a text editor. It is a small HTML file that references the Jasmine source:

<script src="lib/jasmine-2.1.3/jasmine.js"></script>
<script src="lib/jasmine-2.1.3/jasmine-html.js"></script>
<script src="lib/jasmine-2.1.3/boot.js"></script>

The runner references the source files:

<script type="text/javascript" src="src/Player.js"></script>
<script type="text/javascript" src="src/Song.js"></script>

The runner references a special SpecHelper.js file that contains code shared between specs:

<script type="text/javascript" src="spec/SpecHelper.js"></script>

The runner also references the spec files:

<script type="text/javascript" src="spec/PlayerSpec.js"></script>

The Jasmine framework is set up inside the lib/jasmine-2.1.3/boot.js file, and although it's an extensive file, most of its content is in documentation on how the setup actually happens. It is recommended that you open it in a text editor and study its content.

Although, for now, we are running the specs in the browser, in Chapter 8, Build Automation, we are going to make the same specs and code run on a headless browser, such as PhantomJS, and have the results written on the console.

A headless browser is a browser environment without its graphical user interface. It can either be an actual browser environment, such as PhantomJS, which uses the WebKit rendering engine, or a simulated browser environment, such as Envjs.

And although not covered in this book, Jasmine can also be used to test server-side JavaScript code written for environments such as Node.js.

This Jasmine flexibility is amazing, because you can use the same tool to test all sorts of JavaScript code.

In this chapter, you saw some of the motivations behind testing a JavaScript application. I showed you some common pitfalls of the JavaScript language and how BDD and Jasmine both help you to write better tests.

You have also seen how easy it is to download and get started with Jasmine.

In the next chapter, you are going to learn how to think in BDD and code your very first spec.