• Home
  • About Me

Deployment Testing with Node.js and Mocha

You’re an ops guy. A dev has given you a release package, and some basic detail on what ‘working’ looks like. Let’s make our own smoke tests so we can rapidly see if we’re deploying successfully.

If you’re handling a release for a development team, you’ll probably be manually testing the deployed app quite often. Opening the browser, pointing it to your temporary domain, clicking on pages and seeing if certain content shows up. You know, the boring stuff.

And if you’re building a whole new environment, those manual tests are probably happening every few minutes while you update your scripts, build a stack, and see if the app finally works on that stack.

All in all, this manual smoke testing can take up a lot of time.

Automated Testing is for Everyone

Most Operations folks tend to think automated software tests are something that only developers can create.

Nope!

You too can write tests, and you should. There a mythical teams where developers have all the tests an operations team needs to verify applications work successfully, but I’ve never really met them. Most development teams I work with are under the pump and under instructions to build features first, and tests later. Which of course they never get time for, but that’s another discussion.

In this post, I’m going to give you a quick and easy introduction to automated smoke tests with Node.js and Mocha.

Unfamiliar with JavaScript? Fear not, these tests are very straightforward and really don’t need any JS experience.

Easy Street

The code in this blog post is available here. You can clone it and begin adapting it to your needs. Or, follow the next few sections to see how to install from scratch.

The Toolbox

From scratch, you’re going to need Node.js, and Node.js testing frameworks Mocha and Supertest.

Download Node.js here.

Mocha is a test framework for Javascript, while Supertest allow us to make assertions around HTTP calls.

Then install Mocha and Supertest using npm.

npm install -g mocha --save
npm install -g supertest --save

Finally, in a new directory create a file called tests.js

Our Tests

For this example, we’re going to test for certain content on the Google Cloud product site over at cloud.google.com.

Specifically, we’ll be looking for: - Does the home page URL respond successfully? - Does the home page contain the text ‘Secure and fully featured for all enterprises’

Now if you’re a developer, you’re probably upset with me right now. That’s not much to go by! These three tests could easily pass and the site still be fundamentally broken. And I agree with you. But these simple tests are easy to write and for an operations engineer, they’ll save a whole lot of precious time that can be better spent tuning scripts. If these tests pass, it’s enough for you to go back to the developers and say “everything looks good, can you please verify before I put this into production”

Setting up your tests file

We’ll need to set up our file to include the Supertest library. Insert this into the top of your tests.js file.

var request = require('supertest');

Checking for HTTP 200 OK

The simplest test is that you can talk to the web server and it doesn’t hate you.

In your test.js file, add the following:

describe('Homepage', function() {
  var domain = 'https://cloud.google.com/';
  it('should return a HTTP 200 OK', function(done) {
    request(domain)
      .get('/')
      .expect(200)
      .end(function(err, res) {
        if (err) {
          throw err;
        }
        done();
      });
  });
});

What’s happening?

The test above is written in Javascript for Mocha. What makes Mocha so powerful for non-Javascript people like myself is that it doesn’t really require you to know anything about Javascript. The language here is pretty straightforward:

  • describe a test and call it ‘Homepage’
  • domain is the path we domain we will call
  • it is a step that should be run in this test. The text here is entirely for humans to read
  • get a path in domain
  • expect a 200 HTTP OK response
  • end the test by collecting an error and response. If there was an error, throw it. Otherwise, done.

Technically the ‘done’ step is a callback in Javascript, it’s not necessary to know how this works though.

Running our first test

Save the file, and in your command line simply execute mocha test.js. Mocha will step through each test in your tests.js file that you describe.

$ mocha tests.js


  Homepage
    ✓ should return a HTTP 200 OK (845ms)


  1 passing (851ms)

Testing for content

Testing for a 200 OK response is great, but we don’t really if page content loaded successfully. We can add a simple assertion to our existing tests to make content checks on the page.

To do this, we need to use an assertion library like should

npm install should --save

Now we can add some assertions to our script. Here, we’re saying that our response body should have text equalling ‘Secure and fully featured for all enterprises’. To do this, we simply add res.text.should.containEql('Secure and fully featured for all enterprises'); to the end of our test.

var request = require('supertest');
var should = require('should');

describe('Homepage', function() {
  var url = 'https://cloud.google.com/';
  it('should return a HTTP 200 OK', function(done) {
    request(url)
      .get('/')
      .expect(200)
      .end(function(err, res) {
        if (err) {
          throw err;
        }
        res.text.should.containEql('Secure and fully featured for all enterprises');
        done();
      });
  });
});

Running the tests

$ mocha tests.js


  Homepage
    ✓ should return a HTTP 200 OK (1146ms)


  1 passing (1s)

Tip of the iceberg

This is of course just the beginning. But using this model you can create simple tests on applications you build infrastructure for.

user-image

Published Apr 28, 2016

Mike Richardson in Testing

Also found in

  • Testing

Share this article

Managing Chef Cookbooks for OpsWorks with Berkshelf

The need to Educate your Client

Secure Credentials with AWS KMS and Chef

The Consul of Elders

Is the EC2 Container Service a bad idea?

Packer, Windows, AWS and SSL Howto