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.
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.
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.
From scratch, you’re going to need Node.js, and Node.js testing frameworks Mocha and Supertest.
Download Node.js here.
Then install Mocha and Supertest using npm.
Finally, in a new directory create a file called
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
Checking for HTTP 200 OK
The simplest test is that you can talk to the web server and it doesn’t hate you.
test.js file, add the following:
describea test and call it ‘Homepage’
domainis the path we domain we will call
itis a step that should be run in this test. The text here is entirely for humans to read
geta path in
expecta 200 HTTP OK response
endthe test by collecting an
response. If there was an error, throw it. Otherwise, done.
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
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.
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.