Exercise 2 solution

[00:00 - 00:05] I do hope you were able to solve the last exercise. So let's go over my solution.

[00:06 - 00:13] I have created two tests in this describe block. One is for the happy part and the second is for the sad part.

[00:14 - 00:24] In the first test, in the average step, I used just the spy on to spy on the verify method of JWT. We imported JWT from JSON web token.

[00:25 - 00:40] And using just the spy on, we used the mock return value to return an object that contains ID and a number similar to a MongoDB object ID. By using mock return value, this turns the spy to a stop.

[00:41 - 00:58] And we have also created a DB user that mimics how the user is stored in the MongoDB database. We created the mock request, which is an object that contains header, which is also an object and contains authorization and bare token.

[00:59 - 01:18] For our mock response, it's basically just an empty object and the mock nest is a stop using just of FM function. In the next step, we execute our validate JWT middleware function passing the mock request, mock response and mock next.

[01:19 - 01:36] And in the asset step, we expect that mock next must have been called and that the mock request object has a user and it is equal to DB user dot ID to string. In DB user, we have an ID here.

[01:37 - 01:55] This is because in our validate JWT middleware function, if the authorization header is valid, the middleware function will add request dot user and put the user ID in there. And we are asserting that this happened.

[01:56 - 02:04] This is the case for the happy path. If I go ahead to run this test case, it should run without failing.

[02:05 - 02:22] In the second test, which is our sad path, it is similar to our first test. Or in the arrange step, we use just the spy on dot mock implementation and in the function that we pass to mock implementation into return a new error or to throw a new error.

[02:23 - 02:38] Why are we doing this in the validate JWT middleware function? If an error is stronger, we call JWT the verify our middleware function will return response object with status 400.

[02:39 - 02:52] And we can guarantee that that will happen using this just the spy on and mock implementation that shows an error. We created our mock request and our mock response.

[02:53 - 03:09] Our mock response is an object that contains status, which is a stop and it has a mock implementation that returns an object, which contains JSON, which is also a stop. And we created our mock next, which is a stop using just the FM function.

[03:10 - 03:24] In the next step, we execute our middleware function passing the mock request, mock response and mock next. And over here in the set step, we set the mock next was not called.

[03:25 - 03:32] Rather, we also are set the mock response. Those status must have been called and that it was called with 400.

[03:33 - 03:39] I'll go ahead and run this test. And it should run successfully without train errors.

[03:40 - 03:54] Lastly, you will notice that I still stuck with our use naming convention, which is validated WTI, which is our unit on the test and the scenario given valid authorization token. The expectation calls next call back function.

[03:55 - 04:03] The same thing for this test case is our sad path. You should pick a naming convention and stick to that and be consistent in the usage across