Getting started with Jasmine on a Rails project

Posted on 21 March 2014 by Steve Rydz

We’re big fans of TDD here at Easyart. So far this has only applied to our Ruby code, but with JavaScript increasingly becoming a bigger part of our technology stack, we needed to start testing that too.

Choosing the right tool

We chose Jasmine as our testing framework, partly because of its similarity to RSPEC, and also because its really easy to get started with.

You can get started with Jasmine fairly quickly. Their standalone distribution has everything you need to get up and running. Opening the included SpecRunner.html will run the example tests and show you the results. From here you can swap out the example files with your own.

the Jasmine specrunner

Getting up and running on Rails

Once we settled on Jasmine, we needed a way to integrate it into our current workflow, as we don’t want to be running tests manually all the time.

Luckily, there is an official Jasmine gem. To add this to your project add the following to your gemfile:

group: development, :test do
    gem "jasmine"
end

To setup the file structure that the gem expects for your tests, run the following command from your CLI, which will set up all the necessary files and directory structure to begin testing your code:

rails g jasmine:install

Running the tests

There are two ways you can run your Jasmine tests. The first is to run the following rake task:

rake jasmine

This will fire up a web server, accessible at localhost:8888 where you will see an HTML document displaying the results of your tests.

You can also run the tests in continuous integration mode from the command line, which will show you the results in the terminal:

rake jasmine:ci

the Jasmine CLI specrunner

Writing the tests

As I mentioned before, Jasmine is easy to get started with, as long as you are reasonably comfortable with JavaScript, but if like me, you’re new to writing tests it can be hard to figure out where to start.

The key is to write code that is actually testable. The simplest way to do that is to ensure your code returns something. I attended a testing workshop a little over a year ago with Rebecca Murphey, and she described this as:

“Things don’t do things - things announce things”

She also advised to have the following question in mind when writing tests:

“Given this input, do I get this output?”

For more on testable JavaScript, I recommend starting with Rebecca’s A List Apart article.

Going forwards

So far we don’t have as much JavaScript code coverage as we would like, but with a little discipline we’ll eventually get to a place where we can be confident that our code is always working.

comments powered by Disqus