Understanding the basics of Jasmine framework

Although I have a habit of writing unusually lengthy blog posts, I think I can restrain myself this time for quickly explaining you all what Jasmine is and how to write basic test cases using Jasmine. So no unnecessary “presentation logic” this time, it’s all going to be “business logic”.

So, what the hell is Jasmine?

Before you speak, no, I am NOT talking about the Old World shrub which is popular as ornamental and is white in color. Instead, I am talking about a behavior-driven framework which will help you test your JavaScript code.

How should I use it?

Well, the good news is that, unlike many other frameworks, Jasmine has a clean, obvious syntax. It’s so easy that it’s almost a cakewalk to write basic level tests. All you need to worry about is to describe the spec you are going to write in a sentence and then write code for it. Don’t believe me? Take a look at this.

I mean look at that, just look at that! We are describing a test suite using the function describe(). It is a global function in Jasmine which takes a string and a function as its parameters. The string is usually the name of the test suite — what is being tested and the function contains all the code that will implement the suite.

You can describe a spec by calling the global function it(), which, just like describe(), will take a string and a function as its parameters. As expected, the string is the title of the spec and the function is the spec itself. When you are testing a code, you are “expecting” the output of the code to be something. That’s exactly what expect() along with toBe() does. This is just like an assertion. If it is true, then the spec will pass; otherwise, it will fail.

If you want to make a negative assertion, you can do that too. Just use not in between the expect() and toBe() and you’re done. No really, that’s it.

expect(baahubali_release_date).not.toBe(postponed);

These statements are called as Expectations. For every expectation, there has to be an appropriate matcher to complete an assertion. Jasmine provides a rich selection of matchers; toBe() is just one of those. There is toMatch(), toEqual() and many more. Go through the online documentation to find out. Not that I can’t describe them all here. But to make you all read the documentation at least once. Trust me, you won’t look back after reading it.

And all the standard JavaScript rules will apply too. All these are normal js functions after all. All variables declared in describe() will be available in it() as well. And if you want to manually fail a spec, you can do that using the fail() function.

You can write multiple it() calls in a single describe() function. describe() is used to group all the related specs together and only with an appropriate it() will it make sense. The string you passed to the describe() as the first parameter will be concatenated with the string passed to the it(), to describe the complete name of the spec.

Setting up the spec and tearing it down

Of course, you might want to set up few things before you run a spec and then clean up few things after a spec is done. You can do that using beforeEach(), beforeAll() and afterEach(), afterAll().

As the name says, beforeEach() will be called before running every spec, while beforeAll() will be called once before running any spec in the suite. So goes, afterEach() and afterAll().

Disabling a spec / suite

So, everything is alright till now. You’ve written a huge set of test suites and specs and now you want to start testing your code. Obviously, you don’t want to test the advanced functionality of your project before getting the basics right. Apparently, you might want to disable a few tests temporarily and run only a few basic ones. That’s when xdescribe() and xit() comes into picture. :)

If you want to disable any spec, just change the code of the spec from it() to xit(). Even this is self explanatory. x is like a ‘cross-mark’, something which you don’t want or is not necessary at the moment. So if you don’t want to run a spec at the moment, instead of putting it in the comment lines or removing the code, just mark the function as xit() and woila! that spec won’t be tested anymore! Similarly, if you want to disable an entire test suite, you can do that using xdescribe().

Obviously, there are many more things to talk about Jasmine. You have pending tasks. You have spies (plural of spy). You have lots of stuff to learn. All you need is a laptop, an active internet connection, link to the documentation, a text editor (preferably, my all time favorite Brackets), some interest to learn and lots and lots of patience. But don’t forget to install node.js before getting started with Jasmine!

Well, I can at least provide a link to the latest documentation. :)

Sometimes using literal expectations does not clearly describe the requirement that you’re testing. In other words, with Jasmine, it is not always possible to answer all 5 questions that every unit test must answer.

For further details, check out “Why I Use Tape Instead of Mocha and So Should You.”