Actually using Jasmine

Jasmine is a JavaScript testing framework designed to run in a browser which I’ve already discussed. Jasmine itself takes the form of 2 .js files and a .css file. These are loaded into a .html file and called with a short in-line script. This will then run any tests, called specs, which have been loaded into this html file. With all this set up, you just need to open that file in a browser.

There are versions of Jasmine designed to integrate with specific development environments, I’ve no idea how they work. So all this chat will be about the Standalone version. And as ever, this is probably not the best place to come for your tutorial. The Jasmine website is very good as is Andrew Burgess’ tutorial

Nuts and Bolts

Let’s take a look at an example. Fortunately, there’s one bundled in with Jasmine anyway. Head to the Jasmine standalone download page and get a copy to take a look. I’m looking at version 1.3.1, but I’d be surprised if there are any major differences if you come to this from the future and there are later incarnations.

In the zip file there is a folder called lib. This contains Jasmine, you shouldn’t need to mess with these files. In setting up your own project you’re free to move this folder around as long as you keep the filepath right in the link, but apart from that let’s ignore this for now.

There’s also a folder called src. This contains the source files that are being tested in the example. You can ignore this. It’s got nothing to do with Jasmine, it’s just something to test.

The third and final folder is spec. In here are two files, PlayerSpec which contains some tests and SpecHelper which contains a custom matcher. More on what that is later. Open up PlayerSpec.

The two key functions in Jasmine are describe and it. These two work together to create sentences to describe the behaviour each individual spec is testing. The describe function provides a noun for your sentence, defining what object you are testing. Within describe functions will be a collection of its declaring what you want your noun to do. Looking to PlayerSpec, it opens with:

describe("Player", function() {

The first parameter of this function is that noun, the second is a function which contains your its. The first it is:

it("should be able to play a Song", function() {

Which again, has a String as its first parameter which is the behaviour expected and a function as the second one which is the actual test. This comes out in the results as “Player should be able to play a Song”.

You may have also noted that the example contains a describe nested within a describe. This is valid and good, allowing you to group together similar specs and let them share variables or set up and tear down functions.

Jasmine’s set up function is beforeEach which takes a function to run before every spec in its containing describe as its only parameters. Its tear down is afterEach which also takes a single function as a parameter but this is run after every spec.

The final function I want to talk about now is expect. This takes a parameter of some object that you want to test and is followed by a matcher like this:

expect(player.isPlaying).toBeTruthy();

Here we are expecting the property isPlaying of the player object to be true. There are a variety of matchers available in Jasmine, but I’m not going through them all here. The Jasmine webiste provides a list.

As well as using the provided matchers you may want to write your own, custom matchers. To do this create an external file with a beforeEach function in it. inside this, call this.addMatchers, passing in a function with the name of the matcher you want to use. This function needs to take as a parameter the object you are putting into an expect. This function should then compare that against whatever you like and return a boolean to say if it matched or not. You can also define what message is outputted when the spec fails, but I’ve already gone into far too much detail on this relatively minor feature so I’ll leave that here.

That’s all I really want to cover here. Jasmine is capable of much more, with a powerful mocking framework provided in the form of Spies. But they can wait until another time.

Let’s finish up by leaving the spec folder and looking at SpecRunner.html in the base Jasmine folder. For the most part, you can ignore this. In the example it contains four sections of script tags. The first loads in Jasmine itself, the second loads in the source files being tested, the third loads in the specs and the fourth starts Jasmine off. As long as you keep your list of Source and Specs up to date, the rest isn’t of much interest.

Contradicting myself almost immediately, next time I’ll cover ripping apart that html file to use Jasmine with RequireJs.

Advertisements
Tagged , , , ,

One thought on “Actually using Jasmine

  1. […] week I spoke about the basic use of Jasmine, a JavaScript testing framework. The problem presented to us by using Jasmine was that […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Advertisements
%d bloggers like this: