1
00:00:02,190 --> 00:00:08,340
Now of course there is more we could test on our off middleware but I'd say we tested it quite extensively

2
00:00:08,400 --> 00:00:14,070
thus far and therefore I want to move on and I want to move on to our controllers which of course also

3
00:00:14,280 --> 00:00:17,500
house a lot of our core logic.

4
00:00:17,610 --> 00:00:19,650
There we have that off controller.

5
00:00:19,650 --> 00:00:25,140
Obviously we have that feed controller now for that feed controller.

6
00:00:25,140 --> 00:00:28,660
We have routes where we need to be authenticated.

7
00:00:28,680 --> 00:00:32,160
We have a look at our routes here for getting posts.

8
00:00:32,160 --> 00:00:37,370
For example we need to be authenticated for creating posts.

9
00:00:37,380 --> 00:00:41,750
We need to be authenticated essentially for all our post related rulings.

10
00:00:41,760 --> 00:00:48,080
We need to be authenticated and before we take care about that let's have a look at our off controller.

11
00:00:48,090 --> 00:00:54,090
Therefore because these routes don't require us to be authenticated though does it really matter too

12
00:00:54,090 --> 00:00:56,040
much as to question.

13
00:00:56,040 --> 00:01:02,710
Well let's have a look at how we reach our controller functions here like sign up or log in.

14
00:01:02,790 --> 00:01:09,030
We of course reached them through our routes which are defined in the routes folder where we send requests

15
00:01:09,060 --> 00:01:09,750
to India.

16
00:01:09,840 --> 00:01:12,780
So these are the API and points we're exposing here.

17
00:01:13,080 --> 00:01:15,080
And now what did I mentioned earlier.

18
00:01:15,120 --> 00:01:17,070
What what are we testing.

19
00:01:17,070 --> 00:01:18,840
Well we are writing units tests.

20
00:01:18,840 --> 00:01:23,880
We are testing units in our code just as the middleware do you off middleware.

21
00:01:23,880 --> 00:01:30,210
And therefore what will not test is the routing here will not test whether we can send a request to

22
00:01:30,210 --> 00:01:38,370
log in and we execute the log in function in the off controller because that entire for warding off

23
00:01:38,370 --> 00:01:41,880
the request the execution of this method here.

24
00:01:41,910 --> 00:01:43,940
That is all handled by express.

25
00:01:44,050 --> 00:01:48,550
And as I mentioned earlier you don't want to test our libraries.

26
00:01:48,570 --> 00:01:50,520
You want to test your own code.

27
00:01:50,520 --> 00:01:56,790
So we absolutely don't need to test this flow and therefore we'll just test these controller functions

28
00:01:56,790 --> 00:02:00,550
we export here like the sign up or to log in function.

29
00:02:00,570 --> 00:02:06,240
These are the things we want to test now when they're there of course again is a broad variety of things

30
00:02:06,240 --> 00:02:07,170
we can test.

31
00:02:07,260 --> 00:02:14,100
We can test whether we're able to extract e-mail and password from the incoming request though that's

32
00:02:14,100 --> 00:02:19,020
a test that's not too useful because we will simulate the request that's coming in.

33
00:02:19,020 --> 00:02:24,840
So we decide whether that is set or not but we can then test if it behaves correctly if no e-mail is

34
00:02:24,840 --> 00:02:30,560
set for example or if we already have a user with that e-mail.

35
00:02:30,810 --> 00:02:34,530
However there is one new complexity added.

36
00:02:34,530 --> 00:02:42,960
Now we have a database now we're interacting with the User model here and the User model of course is

37
00:02:42,960 --> 00:02:45,240
based on our Mongoose models here.

38
00:02:45,240 --> 00:02:51,840
That's our user model and that behind the scenes uses Mongo D.B. and that of course brings one important

39
00:02:51,840 --> 00:02:57,150
question to the focus how can we test our database.

40
00:02:57,150 --> 00:02:59,920
How can we handle this now.

41
00:03:00,070 --> 00:03:03,990
And turns out there are two main strategies we can follow.

42
00:03:03,990 --> 00:03:11,850
So let's have a look at both strategy number one for testing code that involves database operations

43
00:03:12,270 --> 00:03:22,810
is that we stub or mock the parts that actually rely on database access and what would this mean.

44
00:03:22,830 --> 00:03:31,200
This could mean for example that here when we execute find one we again create a step that returns a

45
00:03:31,200 --> 00:03:34,840
predefined result and we then test if our code behaves correctly.

46
00:03:35,340 --> 00:03:44,070
So for example we might be interested here in finding out how our code behaves when find one frozen

47
00:03:44,130 --> 00:03:44,670
error.

48
00:03:44,670 --> 00:03:52,350
So if we're having trouble interacting with the database or how our code behaves if we don't have a

49
00:03:52,350 --> 00:03:55,420
user with that e-mail address when logging in.

50
00:03:55,530 --> 00:03:59,160
These are two different scenarios and we can write two different tests for that.

51
00:03:59,160 --> 00:04:02,540
Both scenarios should actually throw an error eventually.

52
00:04:02,550 --> 00:04:09,420
Here we throw one manually and if find one fails it also will throw an error but the status code for

53
00:04:09,420 --> 00:04:11,040
example should be different.

54
00:04:11,040 --> 00:04:17,520
The status code should be 500 if the database fails because we use our default code then or we set our

55
00:04:17,520 --> 00:04:18,800
own 401 code.

56
00:04:18,810 --> 00:04:24,900
If we have no user now to test us all first of all create a new file in the test folder and I will named

57
00:04:24,900 --> 00:04:34,080
as of controller dot J.S. and in there just as in the off middleware file I'll import expect from China

58
00:04:34,860 --> 00:04:42,180
and I'll also import sign then because I will start with stubbing that post to find one method that

59
00:04:42,180 --> 00:04:49,740
of course add that user find one method therefore I will also import the user by requiring it from the

60
00:04:49,740 --> 00:04:56,340
user model file just as I'm doing it here in the off controller there we are also importing the user

61
00:04:56,340 --> 00:04:57,750
model.

62
00:04:57,750 --> 00:05:02,670
So now I want to test and log in function and since I want to test that function we need to import this

63
00:05:02,670 --> 00:05:11,010
year as well or in general I'll import my off controller by requiring it from the off file and the controllers

64
00:05:11,010 --> 00:05:12,640
folder.

65
00:05:12,800 --> 00:05:22,310
Now let's add of the scribe block maybe where we test our off controller log in process because even

66
00:05:22,310 --> 00:05:27,380
if we're only testing the off controller in this entire file we might be testing different parts of

67
00:05:27,380 --> 00:05:30,110
that controller like log in and sign up and so on.

68
00:05:30,140 --> 00:05:41,330
So you're old start with log in and then here I want to start by stopping my find one method because

69
00:05:41,340 --> 00:05:46,860
that's the first tactic we can apply we can simply stop that a ways that we don't make a real database

70
00:05:46,860 --> 00:05:47,880
access.

71
00:05:48,150 --> 00:05:56,430
So here what we can do is of course I can again use sign and create a stub create that on the user object

72
00:05:56,610 --> 00:05:58,740
for to find one method

73
00:06:01,550 --> 00:06:05,020
now if I want to you forced us to throw an error.

74
00:06:05,030 --> 00:06:13,590
I can then call the user find one throats now here does will throw an error now by the way.

75
00:06:13,590 --> 00:06:16,710
Of course one issue I have here is that I'm into the scribe blog.

76
00:06:16,710 --> 00:06:20,840
This should go into an IT block that was so into an actual test case.

77
00:06:20,880 --> 00:06:29,350
So here it should flow an hour or if accessing the database fails.

78
00:06:29,370 --> 00:06:31,800
For example.

79
00:06:31,880 --> 00:06:37,010
So now here in that function we define our actual test code and there we set up that stub.

80
00:06:37,200 --> 00:06:43,340
And the important thing here of course is I'm faking that data base fail because I completely replace

81
00:06:43,340 --> 00:06:49,310
to find one method with a stop that will throw an error because the actual thing I wanna check is of

82
00:06:49,310 --> 00:06:52,970
course that we should throw an error with code 500.

83
00:06:52,970 --> 00:06:59,150
So I want to check whether our default status code down there really gets applied correctly.

84
00:06:59,210 --> 00:07:06,470
Now back in the off controller in the end I also want to call restore here.

85
00:07:06,550 --> 00:07:16,480
But in between I of course want to define my expectation and the expectation here is that for my off

86
00:07:16,480 --> 00:07:24,510
controller the log in method when that gets called that it actually throws an error.

87
00:07:24,520 --> 00:07:30,070
Now for that let's have a look at the off controller again and you should now recognize that we have

88
00:07:30,070 --> 00:07:32,080
to async keyword in front of that.

89
00:07:32,290 --> 00:07:38,030
It's not a normal function it's an async function and that means in the end we use promises in there.

90
00:07:38,080 --> 00:07:43,600
You might remember async await is just a more elegant syntax for using promises.

91
00:07:43,630 --> 00:07:49,240
So actually we have a synchronous code in here which is a navigate complexity will have to deal with

92
00:07:49,600 --> 00:07:55,100
because the execution of that code will not happen synchronous.

93
00:07:55,210 --> 00:08:01,080
And that means that by default our expectation you won't work the way you might expect it to work.
