Test for HTTP 400 responses with Mocha and Chai
In this lesson, you will learn how to verify your API server is returning HTTP 400 responses when clients submit incorrect data. Returning HTTP 400 ensures that your clients are notified of the incorrect usage. Testing for them ensures your API returns errors instead of incorrect responses when supplied with incorrect data.
[00:00] We have two different tests here that validate the behavior of our API endpoint when consumers post to the /add endpoint. The first one validates that whenever we supply variables 2 and 3, it returns a sum of 5, and the second, when we supply 4 and 6 that it returns 10.
[00:18] One of the things that makes a great API is that it tests for not only when things are right, but it also has tests to ensure the correct behavior when things are wrong. For instance, our add endpoint here expects two numbers and returns the sum of those, but what if the client doesn't supply numbers?
[00:36] Rather than returning an incorrect response to them, it would be much better to return an error message letting them know what happened. Let's write a test for that to start. We'll say that it should return HTTP 400 for non-number variables.
[00:49] We'll provide our done callback variable, and then like before, we'll request our server instance. We'll post to the add endpoint, set our content type to application/json, and for our variables var1 and var2, we'll post the strings foo and bar, which are not numbers.
[01:08] On end, we'll have our callback, and we'll assert that our response should have a status of 400. Then we'll call our done parameter. Now, if I open my terminal and type mocha, we should have a failing test, and we do.
[01:22] Here's our string. Add post should return HTTP 400, uncaught assertion error, expected code 400 but got a 200 instead. Let's write the code in our add.JavaScript file to make that test pass. In our router post function, we can just do an if statement to say is not a number.
[01:43] In parse variable one, include an or, and do the same for variable two. If either one of those returns true for not a number, we'll set our response status code to 400, as well as return a nice error message for the consumer.
[02:04] Otherwise, we can execute the code as it was before. Let's try our tests again. Now, we have five passing tests, including the one that validates that we return an HTTP 400 status if the client supplies non-numeric variables.
[02:20] That just includes one more step to make our API more resilient and consumer friendly, so that if someone uses our API correctly, we return an error message letting them know that they did that. We've written tests around it so that if that functionality ever breaks, it's going to break that test, and we'll know that we've changed the behavior of our endpoint.
[02:39] Another great way of instructing your consumers how to use your API is to have full documentation around it, which you can do with the OpenAPI spec, or Swagger, as it was formerly known.