Ready to watch this entire course?
Become a member and get unlimited access to the entire skills library of over 4,800 courses, including more Developer and personalized recommendations.Start Your Free Trial Now
- View Offline
- Why use Node.js?
- Installing Node.js
- Understanding the event loop
- Initializing Node.js projects
- Creating modules with getters and setters
- Starting Express applications
- Testing your code
- Working with sessions and databases
- Building command-line tools
- Emitting events and attaching listeners
- Controlling readable streams
Skill Level Intermediate
One of the problems with unit testing a web application is that you have to be able to test the HTTP end points. This typically means you have to start your application on a server. Fortunately Super Test helps us get around this. In this video we'll simulate our HTTP request using super test. Lets go to the exercise files, go to chapter six, video five and then copy the start folder to the desk top. Now got to terminal and change directory to that folder and then type npn install.
Now let's have a look at the code. In the previous video we installed should and supertest. We are now going to use the modules to help us write some unit tests. The first thing we want to test is getting a flight from our sample data. In our data set we have three flights, flight 13,18 and 33. So lets test retrieving flight 18 from the sample set. So, our test is going to say it should return valid flight data for flight 18. And now lets use supertest.
To use supertest, call the supertest function, and then pass your application in as an argument. And then once you have that ready, you can chain calls to super test. So the first call we're going to make is a get request. And we're just going to get flight 18. Next we're going to tell supertest, what response we expect. We're going to expect an okay 200 response. And then finally we can call end. What end does is it takes everything that we've set up in this chain and sends it through supertest and then collects the response.
So end is going to take an anonymous function as the single argument. And it's going to send us an error and a response. Inside this function we're going to assert that we actually got a response that we want. So to do that, I'm going to type res.status. And now I'm going to start using should. So should provides us with several functions we can use on all objects to assert values. So we want the status property of the response object to equal 200.
So I am going to use the equal function. If the status does not equal to 100 should is going to throw an exception, and now finally I am going to move the call to done within this call back this way done is only called when we have a response and we certified that its equal to 200, now lets go back to the command line and run our unit tests If you haven't already installed Mocha as a global module, do so with npm install -g mocha. If you are not an administrator, you may need to add sudu at the beginning of this command So now I'm going to run these unit tests. Just type mocha, and then press return.
So it shows that it did the get request, and it's also showing that both of our unit tests are passing. Let's write some more tests. Sometimes we want a test that when somebody performs an invalid operation, that your application is sending back the appropriate error responses. So to do that, we're going to change this test to say, should return an error for an invalid flight. So we're going to use the same method to build up a request, and then send it, and then receive the response. First we're going to call supertest. And passing our application.
Then we're going to do get request. And we're going to go to flight 99999999. That's a flight that's never going to be in our sample data. Then we're going to expect a 404. Finally let's end this and get the response. In this case the response status should equal 404. And then we'll finally call done. Let's save this file and rerun the unit tests. I'm pressing Up on my keyboard to get Mocha again and then Return.
So now you'll see it did the get request with the 200, and then it also did the get request with the 404. And both unit tests are passing. If I set this to 200 instead, and then save, and then run the tests again That test is going to fail. I'm going to set it back to 404. It's also possible to make more than one request. There's one function in our application that will mark a flight as arrived, and then what we'd like to do is test to make sure that that record reflects that arrival. So, to do that, we're going to write one HTTP request.
And then embed an HTTP request in the response. So let's write that test now. We're going to say, it should mark a flight as arrived. So in this case, we're going to start with super test, pass in the application. We're going to put flight 18 arrived. We're going to expect a 200. And now we're going to end that request. Now, before we make the next request, we want to assert that this request was valid. So first, the status should equal 200.
And then we're going to inspect the body from the response. If those two assertions, pass, we're then going to test to make sure that the record actually changed. We're going to get flight 18. We're going to expect a 200 response. And then we're going to end. This data should also equal 200. And then we're going to inspect the response body. The response body has an actual arrive property. That actual arrive property should be set to a time stamp.
It should not equal undefined. So we're going to type should not equal, and then pass-in undefined. And then finally, we're going to call done here. If I go back to terminal and run mocha again, I'm noticing that it's done, rather than sucess. So let's just change that to done. Now we have four HTTP requests, two of them are being generated for that last test we wrote. As you may already be noticing, unit testing can seem like a bit of an endless task.
How can you know when you've written all the tests you need? Some people advocate having unit tests covering every line of code in your application, while others feel this is counter-productive. Personally, I try to cover all of the end points of the application. It doesn't necessarily mean that every line of code in my application will run during the unit tests. However, I at least have a set of tests covering all the common use cases for the application. Typically, I'll then add tests as specific pieces of functionality or added. Even if it just means testing the same endpoint with different parameters.
Super test makes it possible for you to test an express application without binding it to a server on a specific port. Once you pass your application into Super test you can then change function calls to mock up a request. Finally the end method allows you to insert values in the response. In the next chapter we'll look at connecting to data bases and using them to restore sessions.
Sign up for a Premium Membership to download courses for Internet-free viewing.
Watch offline with your iOS, Android, or desktop app.Start Your Free Trial
After signing up, download the course here or from the iOS/Android App.