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.
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.
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:
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 callit
is a step that should be run in this test. The text here is entirely for humans to readget
a path indomain
expect
a 200 HTTP OK responseend
the test by collecting anerr
or andres
ponse. 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.
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
Now we can add some assertions to our script. Here, we’re saying that our res
ponse 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.
Running the tests
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.