I still remember the satisfaction of being finally able to write the backend part of a bigger app in node and I am sure many of you do it too.
And then? We need to make sure our app behaves the way we expect and one of the strongly suggested methodologies is software testing. Software testing is crazily useful whenever a new feature is added to the system: Having the test environment already set up which can be run with a single command helps to figure out whether a new feature introduces new bugs.
In the past, we’ve worked on Node API Authentication with JSON Web Tokens and Passport.
In this tutorial, we are going to write a simple RESTful API with Node.js and use Mocha and Chai to write tests against it. We will test CRUD operations on a bookstore.
As usual you can build the app step-by-step throughout the tutorial or directly get it on github.
Mocha is a javascript framework for Node.js which allows Asynchronous testing. Let’s say it provides the environment in which we can use our favorite assertion libraries to test the code.
.
Mocha comes with tons of great features, the website shows a long list but here are the ones I like the most:
So with Mocha we actually have the environment for making our tests but how do we do test HTTP calls for example? Moreover, How do we test whether a GET request is actually returning the JSON file we are expective, given a defined input? We need an assertion library, that’s why mocha is not enough.
So here it is Chai, the assertion library for the current tutorial:
Chai shines on the freedom of choosing the interface we prefer: “should”, “expect”, “assert” they are all available. I personally use should but you are free to check it out the API and switch to the others two. Lastly Chai HTTP addon allows Chai library to easily use assertions on HTTP requests which suits our needs.
Time to setup our Bookstore!
Here is the project directory for our API, something you must have seen before:
Notice the /config
folder containing 3 JSON files: As the name suggests, they contain particular configurations for a specific purpose.
In this tutorial we are going to switch between two databases, one for development and one for testing purposes, thus the files contain the mongodb URI in JSON format:
NB: default.json
is optional however let me highlight that files in the config directory are loaded starting from it. For more information about the configuration files (config directory, file order, file format etc.) check out this link.
Finally, notice /test/book.js
, that’s where we are going to write our tests!
Create the package.json
file and paste the following code:
Again the configuration should not surprise anyone who wrote more than a server with node.js, the test-related packages mocha, chai, chai-http are saved in the dev-dependencies (flag --save-dev
from command line) while the scripts property allows for two different ways of running the server.
To run mocha I added the flag --timeout 10000
because I fetch data from a database hosted on mongolab so the default 2 seconds may not be enough.
Congrats! You made it through the boring part of the tutorial, now it is time to write the server and test it.
Let’s create the file server.js
in the root of the project and paste the following code:
Here are the key concepts:
The remaining lines of codes are nothing new, we simply go through requiring all the necessary modules, define the header options for the communication with the server, craete the specific roots and eventually let the server listen on a defined port.
Time for our book model! Create a file in /app/model/
called book.js
and paste the following code:
Our book schema has a title, author, the number of pages, the publication year and the date of creation in the db. I set the versionKey to false since it’s useless for the purpose of the tutorial.
NB: the exotic callback syntax in the .pre()
function is an arrow function, a function who has a shorter syntax which, according to the definiton on MDN , “lexically binds the this value (does not bind its own this, arguments, super, or new.target). Arrow functions are always anonymous”.
Well, pretty much all we need to know about the model so let’s move to the routes.
in /app/routes/
create a file called book.js and paste the following code:
Here the key concepts:
updatedBook()
we use Object.assign
, a new function introduced in ES6 which, in this case, overrides the common properties of book with req.body
while leaving untouched the others.We finished this section and actually we have a working app!
Now let’s run the app and open POSTMAN to send HTTP request to the server and check if everything is working as expected.
in the command line run
in POSTMAN run the GET request and, assuming the database contains books, here is the result:
The server correctly returned the book list in my database.
Let’s add a book and POST to the server:
It seems the book was perfectly added. The server returned the book and a message confirming it was added in our bookstore. Is it true? Let’s send another GET request and here is the result:
Awesome it works!
Let’s update a book by changing the page and check the result:
Great! PUT also seems to be working so let’s send another GET request to check all the list:
All is running smoothly…
Now let’s get a single book by sending the id in the GET request and then delete it:
As it returns the correct book let’s try now to delete it:
Here is the result of the DELETE request to the server:
Even the last request works smoothly and we do not need to doublecheck with another GET request as we are sending the client some info from mongo (result property) which states the book was actually deleted.
By doing some test with POSTMAN the app happened to behave as expected right? So, would you shoot it to your clients?
Let me reply for you: NO!!
Ours is what I called a naive test because we simply tried few operations without testing strange situations that may happen: A post request without some expected data, a DELETE with a wrong id as parameter or even without id to name few.
This is obviously a simple app and if we were lucky enough, we coded it without introducing bugs of any sort, but what about a real-world app? Moreover, we spent time to run with POSTMAN some test HTTP requests so what would happen if one day we had to change the code of one of those? Test them all again with POSTMAN? Have you started to realize this is not an agile approach?
This is nothing but few situations you may encounter and you already encountered in your journey as a developer, luckily we have tools to create tests which are always available and can be launched with a single comman line.
Let’s do something better to test our app!
First, let’s create a file in /test
called book.js
and paste the following code:
Wow that’s a lot of new things, let’s dig into it:
You must have noticed the we set the NODE_ENV variable to test, by doing so we change the configuration file to be loaded so the server will connect to the test database and avoid morgan logs in the cmd.
We required the dev-dependencies modules and server itself (Do you remember we exported it by module.exports
?).
We defined should
by running chai.should()
to style our tests on the HTTP requests result, then we told chai to use chai HTTP.
So it starts with “describe” blocks of code for better organizing your assertions and this organization will reflect in the output at command line as we will see later.
beforeEach
is a block of code that is going to run before each the describe blocks on the same level. Why we did that? Well we are going to remove any book from the database to start with an empty bookstore whenever a test is run.
And here it comes the first test, chai is going to perform a GET request to the server and the assertions on the res variable will satisfy or reject the first parameter of the the it
block it should GET all the books. Precisely, given the empty bookstore the result of the request should be:
Notice that the syntax of should assertions is very intituitive as it is similar as a natural language statement.
Now, in the command line run:
```javascript npm test ```
and here it is the output:
The test passed and the output reflects the way we organized our code with blocks of describe
.
Now let’s check our robust is our API, suppose we are trying to add a book with missing pages field passed to the server: The server should not respond with a proper error message.
Copy and paste the following code in the test file:
Here we added the test on an incomplete /POST request, let’s analyze the assertions:
errors
.Errors
should have have the missing field pages as property.pages
should have the property kind
equal to required in order to highlight the reason why we got a negative answer from the server.NB notice that we send the book along with the POST request by the .send()
function.
Let’s run the same command again and here is the output:
Oh Yeah our test test is correct!
Before writing a new test let me precise two things:
Let’s send a book with all the required fields this time. Copy and paste the following code in the test file:
This time we expect a returning object with a message saying we succesfully added the book and the book itself (remember with POSTMAN?). You should be now quite familiar with the assertions I made so there is no need for going into detail. Instead, run the command again and here is the output:
Smooth~
Now let’s create a book, save it into the database and use the id to send a GET request to the server. Copy and paste the following code in the test file:
Through the assertions we made sure the server returned all the fields and the right book testing the two ids together. Here is the output:
Have you noticed that by testing single routes within independent blocks we provide a very clear output? Also, isn’t it so efficient? We wrote several tests that can be repeated with a single command line, once and for all.
Time for testing an update on one of our books, we first save the book and then update the year it was published. So, copy and paste the following code:
We wanna make sure the message is the correct Book updated! one and that the year
field was actually updated. Here is the output:
Good, we are close to the end, we still gotta test the DELETE route.
The pattern is similar to the previous tests, we first store a book, delete it and test against the response. Copy and paste the following code:
Again the server returns a message and properties from mongoose that we assert so let’s check the output:
Great, our tests are all positive and we have a good basis to continue testing our routes with more sophisticated assertions.
Congratulation for completing the tutorial!
In this tutorial we faced the problem of testing our routes to provide our users a stable experience.
We went through all the steps of creating a RESTful API, doing a naive test with POSTMAN and then propose a better way to test, in fact the main topic of the tutorial.
It is good habit to always spend some time making tests to assure a server as reliable as possible but unfortunately it is often underestimated.
During the tutorial we also discuss a few benefits of code testing and this will open doors to more advanced topics such as Test Driven Development (TDD).
Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases.
While we believe that this content benefits our community, we have not yet thoroughly reviewed it. If you have any suggestions for improvements, please let us know by clicking the “report an issue“ button at the bottom of the tutorial.
This textbox defaults to using Markdown to format your answer.
You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!
Thank you so much for this article. Really helped me understand what goes into unit testing.
Thank you bro! this save my day, really nice explained!! You ROCK!!! Cheers!!
Thank you very much! Great article. What if I have login needed for using routes? I believe that mocha has way to do it.