Have a Question?

Introduction

Tests are important; they provide a safeguard for your applications or APIs. As beginners, it is possible to be oblivious of the need to write tests that cover the important parts of what you are building. Yet you will meet with it as you make progress as a developer.

In a previous tutorial, you learned how to build an API with Node.js. If you have not gone through it, I suggest you do so before continuing with this. In this tutorial, you will be writing tests for an API built using Node.js and Express. At the end of this tutorial, you will know how testing works in Node.js, and you will be able to build functional and tested APIs.

Testing Tools

You will be making use of Mocha, Expect, and Supertest.

Mocha is a JavaScript test framework which makes asynchronous testing simple and fun. Mocha comes with tons of great features which can be found on the website. You will be making use of a handful of them.

Expect is an assertion library that makes it easy for you to make better assertions. You will see how that works. Supertest provides a high-level abstraction for testing HTTP. This is needful as you will be testing an API.

Enough talk, time to write some code.

Project Setup

I have a to-do list project already set up for you. The model, config file, and part of the app.js are already done for you. Go over to GitHub and clone the repository. Or you can simply do:

The before block cleans your Todo database, then inserts the to-dos set above. This ensures that you have a stable amount of entries in your database so your tests do not run into issues.

With that done, you can write the test for the POST request. For your POST request, you will write two tests. The first will make a request for a valid to-do and be successful. The second will make a request with an invalid body, and this should not create a new to-do.

You make a POST request to the /todos path of your API, sending the to-do you created as the body of the request. You expect the status code for the request to be 200 and the body of the to-do to equal the value of text.

An error is returned if there is any, and this will cause the request to end. Thus the next block of code will not run. If no error is encountered, the flow continues.

A request is made to the database to find the created to-do. You expect the length of the to-dos in the database to be 1, and the text of the to-do to be equal to the value of text.

This is the test made with invalid body data.

A POST request is made to the /todos path. This time, you are sending a request with no body. You expect to get a 400 request. No need to check the body as you are not sending any. If an error is encountered, it gets returned and the code stops running.

If no error is encountered, a request is made to the database to check the length of the to-dos. We expect that the database will contain only 2, which are the to-dos created at the beginning.

To get this test passing, go to your server.js file and drop in the code needed for the POST request.

GET Request Test

This is simple—the test should return the length of to-dos available in the database. As you already know, the length of the todos should be 2. Why? You guessed right. At the beginning of the test suite, you created a beforeEach block that cleans your database and inserts new to-dos each time the test suite is run.

To test that the request to get all to-dos works, here is the code for that.

In the above, you are making a GET request to the /todos path. This time, you are not passing anything as the body of the request because it is a GET request. You expect to get a response with the status code of 200. Then you expect that the length of the to-dos will be 2.

When you run the test, you should get an error. Try getting the error to pass on your own.

I bet you got that to work. Here is the code to get the test to pass; compare it with your solution.

When a GET request is made to the /todos path, you want to find every to-do in the Todo collection and return them as to-dos. Adding this to server.js causes the test to pass.

Next, you’ll write three tests for the GET request made to retrieve individual to-dos. The first should retrieve and return the to-do. The second and third should return 404 error in cases where the to-do is not found.

Open up your server.test.js and create a new describe block with the first test case.

This test makes a GET request to retrieve the first to-do available in your database. You expect to get a 200 status code, and then check that the text value of the to-do is the same as the one created.

You set the id of the to-do to a variable called hexId. Next, a DELETE request is made to the path of the to-do, using the ID. You expect to get a 200 response, and the to-do obtained to match the value of hexId.

If any error is encountered, it is returned.

If no error, the test goes further to query your database using the ID saved as the value of hexId. Since a DELETE request has been previously sent, the test expects that the to-do matching that ID does not exist.

Next, you want to test that when a request is made to delete a to-do that does not exist, the response contains a 404 error. It is important to have this, as it is not possible to delete a to-do twice. Here is how the test for this should look.

Conclusion

At this point, you now know how to set up a test suite when building an API using Node.js. You have used Mocha, Expect, and Supertest to test an API. One advantage of doing this is that you do not need to always fire up Postman when building your API. With your test, you can get to know what is broken.

Before we wrap up, note that JavaScript has become one of the de facto languages of working on the web. It’s not without its learning curves, and there are plenty of frameworks and libraries to keep you busy, as well. If you’re looking for additional resources to study or to use in your work, check out what we have available on Envato Market.

Using what you now know, you are good to explore the world of testing.