Exercise 1 solution (Testing the Login Controller)
Get the project source code below, and follow along with the lesson material.
Download Project Source CodeTo set up the project on your local machine, please follow the directions provided in the README.md file. If you run into any issues with running the project source code, then feel free to reach out to the author in the course's Discord channel.
This lesson preview is part of the Pain Free Mocking with Jest course and can be unlocked immediately with a \newline Pro subscription or a single-time purchase. Already have access to this course? Log in here.
Get unlimited access to Pain Free Mocking with Jest, plus 70+ \newline books, guides and courses with the \newline Pro subscription.
[00:00 - 00:11] I hope you were able to create the test cases and you got your test cases to run successfully. Let's review the login controller again.
[00:12 - 00:23] In the login controller, we read the user email and password from the request object. And then we query the database using findByEmail method.
[00:24 - 00:37] This is a new method that I added to the user service file. It accepts an email and it queries the database for user record that has that email.
[00:38 - 01:00] So back in the login controller, once we read the user from the database, we then check if the password is correct. If the user doesn't exist, we return status 400 and the same if the password isn't correct, we return the status 400.
[01:01 - 01:15] Next we create a token. Finally, we return our response with 200 status code and in the body of the response, we return the user record and the JWT token.
[01:16 - 01:28] Now let's review our test cases. And before each hook, we clear the database using delete many and you will notice that we stuck with the user naming convention.
[01:29 - 01:45] This is the unit on the test, the login route and the scenario or the input and our expectations, which is that it returns 200. In the after all hook, we closed our MongoDB connection and also we closed the app.
[01:46 - 02:06] In this test case, which is our happy path, we created a valid bequipped password from this string and we have the user variable that will add to the body of the request. But first in the arrange step, we add this user record to the database.
[02:07 - 02:30] This is so that we have an existing user for our login controller. In the act and asset step, we made a request using supertest against our server and the request is a post request and this is the HTTP endpoint and in the body of the request, we sent our email and password.
[02:31 - 02:44] Lastly, we made an assertion that the response should be 200. I go ahead and run this and it should run successfully.
[02:45 - 03:29] In this other test case, which is our sad path, because we've already cleared the database in our before each hook, when this test case runs, the database will be empty and hence the user that will send in the body of the request will actually be invalid. In the act and asset step, we made a request against our server using this HTTP endpoint and we are set that the response should be 100 status code and the JSON returned also should be this value status failed in correct login details.
[03:30 - 03:36] In correct login credentials, I mean, I go ahead and run this test case and it should Run successfully, so there you have it.