Welcome to Part 5 of this review of the Pluralsight course RESTful Web Services with Node.js and Express by Jonathan Mills.

Jonathan is a JavaScript and Node.js expert working mostly in the MEAN Stack with individuals and companies to help build their technical skills to cope with the constantly changing landscape of software development.

He is also an ASP.NET insider and an international speaker focusing on JavaScript both in the browser and on the server.

Node.js and Express gives us the ability to write lightweight, fast, scalable APIs quickly.

Also in this series:

Part 1 – What is REST?
Part 2 – Getting Data
Part 3 – Posting Data
Part 4 – Updating Data
Part 5 – Testing
Part 6 – HATEOAS

Testing Data

Controllers

We currently have all of our routing code in bookRoutes.js.

We want to separate some of this out into a controller.

We have some anonymous functions that we want to move into the controller.

We begin with post, and this code uses Book. We don’t want to create an instance of Book inside our controller, because we want to be able to mock it when we write our unit tests.

We use the revealing module pattern here.

Postman and Bugs

In Postman, Jonathan posts and creates a new book without a title. That’s a bug.

Unit Tests with Mocha

We create bookControllerTests.js but before we can write test code we need Mocha. We also want should and sinon:

npm install gulp-mocha should sinon –save

We need to require in should and sinon, but not mocha.

Jonathan introduces Mocha’s BDD style syntax: describe blocks and it blocks.

To unit test we need a “mock” book. Strictly speaking we write a stub rather than a mock here. Our request object req is also stubbed with an author with the name ‘Jon’, in the body.

res is more difficult because we need to call some functions with it.

We use a couple of Sinon spies for this: one for status and one for send.

The test asserts a couple of things. The first assert is that the status is called with 400 and has a “Bad Status” message.

For a longer look at Unit Testing with Mocha and Sinon see Testing Clientside JavaScript. This also covers QUnit and Jasmine.

Gulp-mocha

Gulp-mocha is used for running our Mocha tests using Gulp.

But it isn’t just a case of everything works right away: we need to update our gulpfile.js with a new task.

We write a task called ‘test’ which reads any JS files in our tests directory and pipes them to gulpMocha.

Once that’s done we type gulp test to run our test. And it fails. Because we are doing Test Driven Development this is the result that we want.

After implementing the correct production code, we rerun our test and see that it passes.

Integration Tests with Supertest

Unit tests only test thin slices of our application. Here we will test the HTTP calls end to end.

We need to install a couple of new packages first:

npm install supertest gulp-env –save-dev

Then we require in ‘gulp-env’ and ‘supertest’.

We update our ‘test’ gulp task setting env to the ‘Test’ environment, and update our app.js code to use a different Mongo database when we are running in a Test environment.

We create bookIntegrationTests.js, and we are testing with Mocha again.

Agent is what we use from supertest to execute all of our HTTP calls.

The first integration test is:

“Should allow a book to be posted and return a read and _id”

I am quite impressed by supertest from this demo. It seems like a very useful tool, and it has 3,907 Github stars at the time of writing so many others seem to agree with me.

Supertest is built on top of superagent which is even more popular and has over 8,000 stars.

As Jonathan says, these tests let us know that all of the moving pieces are working together and doing what we expect them to do.

The final part – HATEOAS is coming soon