Test your JavaScript with Jasmine part 1

At Rainforest, we love testing as it is the best way to ship high quality software. In addition to using Rainforest tests, we use a bunch of testing tools for our code and one is Jasmine, to test our Backbone.js frontend app.

Jasmine was built by our friends at Pivotal Labs. In this post I'll show you how to test some basic JS code with Jasmine.

What is testing?

While this post is not an introduction to testing, testing is all about verifying that your code does what it is expected to do with automated tools.

Basic example

Let's take a basic evenOrOdd function returning you "even" if the value is even, and "odd" if it's odd:

javascript var evenOrOdd = function(value) { if(value % 2 == 0){ return 'even'; } else { return 'odd'; } };

How can we verify that this code works as expected? We will take a Test-driven development (TDD) approach to this, so we will start with no code at all.

This is the content of our EvenOrOdd.js file right now:

javascript // nothing here, yet.

First, we need a test suite. A test suite for Jasmine starts with a call to the describe function which takes two parameters: a description (string) and a function.

EvenOrOddSpec.js content:

describe("evenOrOdd", function() { });

This is our test suite for evenOrOdd.

The second parameter will include our tests. Let's start with our first test. A test is made of a call to the it function, taking two parameters: a description (string) and a function. Inside the function, we add an expectation. Let's see how that looks like:

describe("evenOrOdd", function() { it("returns 'odd' when the number is odd", function(){ expect(evenOrOdd(1)).toEqual('odd'); }); });

The previous example is calling our evenOrOdd function with "1" as the parameter and Jasmine is expecting the return value to be "odd".

Running the tests give us this result right now:

We are getting this because evenOrOdd is not even defined, let's do this:

var evenOrOdd = function(){


What would happen if we were to run the tests again?

We had a different result, slowly bringing us closer to what we want.

In the TDD world, there is a thing we call "red green refactor" which means the first step is write a test that fails due to the not behaving as expected (or not being present). The green part, is writing the minimum to make that test pass. Finally, the refactor part, is making the appropriate change to have nice and clean code doing what it should be doing.

We did the "red" part of it, let's make it pass:

var evenOrOdd = function(){ return 'odd'; };

This test will pass:

Screenshot of the passing test

Well, that's cool, but it's not exactly the end result we want, so let's expand our test suite

describe("evenOrOdd", function() {
 it("returns 'odd' when the number is odd", function(){ expect(evenOrOdd(1)).toEqual('odd');

it("returns 'even' when the number is even", function(){
 expect(evenOrOdd(2)).toEqual('even'); });

Running our tests will now have one failure, and one success:

Well, that is expected as our code is not appropriate, so let's fix it:

javascript var evenOrOdd = function(value) { if(value % 2 == 0){ return 'even'; } else { return 'odd'; } };

Now our code works as we want, it is covered by some tests. Obviously, this is very basic and non-realitisc code, but that gives you a rough idea.

Click here to go to the repo with the code and tests from this post.

For this example, I only used toEqual, but there are other "matchers" you can use for your tests, here are a few more:

expect(a).toContain("bar"); expect(a.bar).toBeUndefined(); expect(foo).toEqual(1); expect(foo).toBe(true);

You can see a longer list in the official documentation.

There is a whole lot more you can do with Jasmine. You can share setup steps between tests in beforeEach or afterEach, you can expect a function to be called with "spies", etc. Read Test Your JavaScript with Jasmine, Part 2.

Related articles

Discrete optimization for on-call scheduling

5 Foolish Reasons You're Not Using Heroku

We’ve been using Heroku extensively at Rainforest QA since early 2012 to run our automated QA testing service. It’s stable, it makes economic sense, and it precisely suits our needs. Here are the main arguments I hear against Heroku, and why I think they are (mostly) fallacious.

Test your JavaScript with Jasmine part 2

I am going to show you a few more things that will make you more efficient at using Jasmine to test your JavaScript.

Optimal Environment Setup

In this post we're going to look at optimal environments for webapps. This is part two in a series - the first post looks at what are environments for?