Skip to content

Quick Introduction: Mocha, Chai and Chai-http Test Express API Auth Endpoints

Posted in Javascript

Irrespective of the programming language or framework used, Obeying the Testing Goat is essential and leads to reduced error-prone programs or applications. Let’s put Mocha, Chai and Chai-HTTP to use and see how we can test an Express API endpoints behind authentication.

As much as testing is generally not fun to write, we all appreciate the benefits. Fortunately, I’m not here to tell you what goodness testing comes with, and how it can improve your code base if you have good test coverage.

In this article, let’s explore how to handle testing API endpoints which are protected. In our setup, we’ll be using JWTs, therefore, a way to maintain the JWT in subsequent tests without refreshing is important, in order to pass a flow.

Our stack for this article are:

  • Express (duh)
  • Mocha (npm install --save-dev mocha)
  • Chai and Chai-HTTP (npm install --save-dev chai chai-http)

Of course, this article assumes you have a bit of experience using at least, Javascript of which Express is made of.

If you’ve played with Express before, then that’s fine. In any, I think developers interested in testing know their way around.

So let’s get in now that we have our needed packages installed.

What to Test?

In short, we wanna test these:

  1. /GET login and /POST login
  2. /GET register and  /POST register
  3. /POST register, /POST login and then /GET user (a protected endpoint)

I won’t go over the steps for 1. and 2. as the third point will take us through all that, and throw in the accessing a protected route, namely, /GET user, which returns a User info.

Therefore, our /GET register and /POST register endpoints can like this (for brevity, some code part will be cut short)

Our /GET login and /POST login can look on the other hand, like this:

Nothing interesting happening in the above snippet though. We’re logging in!

Now let’s test!

Testing, Shall we?

First of all, add something small to your package.jsonfile indicating a command to run the test.

With the above in our package.json file, we can simply do, npm test to trigger the running of the test. But we even have no test file yet.

Let’s do that.

Now, go back and read through the code, isn’t it just beautiful, how writing tests with Chai mean we get to use common English expressions.

The steps involved in the above snippet is this:

  • To make request to protected pages, we need to have an auth token
  • To have an auth token, we need to login
  • To be able to log in, we need to have an account.
  • Therefore, we create an account, then login, then extracting the auth token, we make a request to the protected page/endpoint.
  • We signal the end of our tests with the done() callback. Indeed, we’re done!

Nesting your a request, yet in the .end( .. ) chained sections means we get access to the either err or res objects from the previous request. With that, the rest is history.

We get to manipulate our res object just like we do in usual Express. Nothing special.

Checkout the Chai docs to see more available expressions: http://devdocs.io/chai/api/bdd/index

When we run the above, if all goes well, we can see something like this

 

All our tests passed. Don’t say because I say it passed, it passed for you too. Play with the examples above. Create your own tests, as I have in my test results above.

You can decide to test different scenarios of your application, thus, if something doesn’t go right in future updates and code increments you can pick them up easily.

Writing test.should.be.fun and using Chai and Chai-http makes the experience easier.

Conclusion

Lemme know in the comments if you don’t understand any parts. Will be happy to help. Otherwise

I hope to write more tests for my upcoming Progressive Web App, which will live at khophi.com. It is from the codebase of the project which the above snippets were taken from.

Hope to you see you in the next one.

 

  • kessir

    Great reminder that testing is not that difficult!
    This is no big deal but you should use ‘const’ by default and only use ‘let’ if you need to reassign variables. Also, if you’re on Node 8+, you should try async/await. In my experience, it makes tests more readable.

    • Yeah, the ‘const’, that’s a good point. I’m using Node 7 at the moment. Will give the async/await approach a try when I move to the Node 8+

      Edit: About the ‘const’, where exactly can I use it?