This is the 19th Testing Tuesday episode. Last week we tested asynchronous JavaScript operations with Jasmine.

UPDATE: If you don't want to follow along with the text in this article I encourage you to skip to the end of the blog post and watch the video. I explain everything in detail there.

We've already covered Jasmine in the last three Testing Tuesday episodes. Especially Testing Tuesday #16 will get you up and running if you're not familiar with Jasmine already.

After a few episodes about testing your web frontend JavaScript code with Jasmine, we will show you how to test node.js applications with Jasmine today. We'll use the excellent jasmine-node package to run unit tests from our console.

There are a few testing libraries that have become popular in testing Node.js applications. There's Qunit, which is mainly popular for being the testing framework jQuery uses. We demonstrate how to test synchronous and asynchronous callbacks with QUnit in Testing Tuesday #21. Another popular choice is Mocha which impresses with feature richness and nice test result formatters.

My favorite JavaScript testing framework is Jasmine which is originally meant for browser testing. I love Jasmine for its mocking abilities which are especially useful for unit testing. Fortunately there exists the npm package jasmine-node which makes Jasmine available for node.js apps as well.

You can give jasmine-node a try by running npm install jasmine-node -g. This will install jasmine-node globally, so we're able to run jasmine-node from the command line.

I'll give you a short intro to jasmine-node, but you can also watch the screencast at the bottom of the page if you don't feel like reading or you want to listen to my gentle voice.

I write a calculator module which has got only one method multiply that isn't implemented yet:

#!javascript
# calculator.js
exports.multiply = function (multiplier1, multiplier2) {
};

I put my specs into a spec folder, so when I run jasmine-node, I pass the folder as an argument: jasmine-node spec. You can also run jasmine-node without arguments which will list all available options.

I write my specs into the file spec/calculator-spec.js. You should always finish your jasmine spec filenames with spec.js because jasmine-node will only run these files by default.

#!javascript
# spec/calculator-spec.js
var calculator = require("../calculator");
describe("multiplication", function () {
  it("should multiply 2 and 3", function () {
    var product = calculator.multiply(2, 3);
    expect(product).toBe(6);
  });
});

In this file I require my calculator module. The example checks the result of multiplying 2 and 3. When I run the spec, it informs me that it Expected undefined to be 6.

So let's make this spec work. The easiest solution is to return 6:

#!javascript
# calculator.js
exports.multiply = function (multiplier1, multiplier2) { this is a very long text that exceeds the blog page.
  return 6;
};

Now it works! But it's tedious to run the tests manually after every little change. Instead, we can run jasmine-node --autotest to let the specs run on every change automatically.

So far our multiplication isn't quite complete, so let's add a second spec:

#!javascript
# spec/calculator-spec.js
it("should multiply 3 and 5", function () {
  var product = calculator.multiply(3, 5);
  expect(product).toBe(15);
});

And as soon as I save the file, the specs start running. Great! Let's change the implementation now to return 15:

#!javascript
# calculator.js
exports.multiply = function (multiplier1, multiplier2) {
  return 15;
};

But when I save the file, nothing happens. That's because jasmine-node will only look for changes in the spec folder. We can overcome this misery by calling jasmine-node on the root folder instead: jasmine-node . --autotest. But now jasmine-node will also look for spec files in the whole project. Especially in larger projects this will make autotest less snappy because it will take longer to look up the files. We can pass another option to solve this problem: jasmine-node spec --autotest --watch .. Now jasmine-node listens to changes on the whole project, but only look for specs in the spec folder.

When we save the file again now, our first spec fails. Now let's correct our implementation:

#!javascript
# calculator.js
exports.multiply = function (multiplier1, multiplier2) {
  return multiplier1 * multiplier2;
};

This way it works!

There are some more options for jasmine-node and I highly encourage you to check them out by running jasmine-node without arguments or by reading the GitHub Readme.

Also check out the the other Testing Tuesdays about Jasmine:

• In Testing Tuesday #17 we introduce Jasmine method spies and how they help you isolate your unit tests

• And in Testing Tuesday #18 we test asynchronous Javascript method calls with Jasmine

• And finally in Testing Tuesday #20 we show you how to continuously deploy a node.js application with Jasmine and the Codeship.

https://fast.wistia.com/embed/medias/fp99jlcsj7.jsonphttps://fast.wistia.com/assets/external/E-v1.js

Having an automated test suite helps a lot when developing software. But it also makes it possible to deploy your code automatically on every change! Next week we'll show you how to continuously deploy your node.js applications to Heroku with the Codeship. If you've got any questions or suggestions, please leave us a comment!

PS: If you liked this article you might also be interested in one of our free eBooks from our Codeship Resources Library: Efficiency in Development Workflows

• Testing Tuesday #16: JavaScript Testing with Jasmine

• Jasmine

• jasmine-node

• Click here to tweet this article

Ahoy and welcome! My name is Clemens Helm and this is Codeship's Testing Tuesday episode 19. After a few episodes about testing your web frontend JavaScript code with Jasmine, I will show you how to test node.js applications with Jasmine today.

We've got a very basic node.js application containing a calculator module. The calculator has got only one method "multiply", which we need to implement. We want to do this in a behavior-driven way using Jasmine.

#!javascript
# calculator.js
exports.multiply = function (multiplier1, multiplier2) {
};

We've already covered Jasmine in the last three Testing Tuesday episodes. Especially Testing Tuesday #16 will get you up and runnig if you're not familiar with Jasmine already. I'll link to it in the further info section.

We can install Jasmine for node.js by running npm install jasmine-node -g. We provide the -g option to install it globally, so we're able to run jasmine-node from the command line.

Once this is done we can run jasmine-node which will provide us with all available options. I would like to put my specs into a spec folder, so I can pass the folder as an argument to jasmine-node and it will run all the spec files for me. mkdir spec

jasmine-node spec looks for specs in the spec directory and finishes successfully, because none of our 0 specs failed. Although having a green test suite is worthwhile, adding some specs to it makes it even nicer.

#!shell
mate .

Let's create a file spec/calculator-spec.js. You should always finish your jasmine spec filenames with spec.js because jasmine-node will only run these files by default.

#!javascript
# spec/calculator-spec.js
var calculator = require("../calculator");
describe("multiplication", function () {
  it("should multiply 2 and 3", function () {
    var product = calculator.multiply(2, 3);
    expect(product).toBe(6);
  });
});

In this file we require our calculator module. Then we add an example to check the result of multiplying 2 and 3. When we run the spec, it tells us that it Expected undefined to be 6.

So let's make this spec work. The easiest way to make this happen is by letting our function return 6:

#!javascript
# calculator.js
exports.multiply = function (multiplier1, multiplier2) { this is a very long text that exceeds the blog page.
  return 6;
};

When we run our specs again, it works! But it's a little cumbersome to run the tests manually after every little change. Instead, we can use jasmine-node's autotest option to let it run the specs on every change automatically.

#!shell
jasmine-node spec --autotest

Let's write another spec now:

#!javascript
# spec/calculator-spec.js
it("should multiply 3 and 5", function () {
  var product = calculator.multiply(3, 5);
  expect(product).toBe(15);
});

And as soon as we save the file, the specs start running. Great! Let's change our implementation now to return 15 and see what happens:

#!javascript
# calculator.js
exports.multiply = function (multiplier1, multiplier2) {
  return 15;
};

When we save the file, nothing happens. That's because jasmine-node will only look for changes in the spec folder. We can overcome this misery by calling jasmine-node on the root folder instead of the spec folder: jasmine-node . --autotest. But this will also instruct jasmine-node to look for spec files in the whole project. Especially in larger projects this will make autotest less snappy because looking up the files will take longer. We can pass another option to solve this problem: jasmine-node spec --autotest --watch .. Now jasmine-node listens to changes in the whole project while only looking for specs in the spec folder.

When we save the file again now, our first spec fails. Now let's correct our implementation:

#!javascript
# calculator.js
exports.multiply = function (multiplier1, multiplier2) {
  return multiplier1 * multiplier2;
};

There are some more options for jasmine-node and I highly encourage you to check them out by running jasmine-node without arguments or by visiting the GitHub readme.

This was it for today, I hope you found it useful! Next week I’ll show you how to continuously deploy your node.js applications to Heroku using Jasmine and the Codeship! Have a beautiful week and never give up, but always stay shipping!