1
00:00:01,400 --> 00:00:02,950
Our index right handlers put together.

2
00:00:02,960 --> 00:00:04,680
So let's write out a quick test or two.

3
00:00:04,700 --> 00:00:08,570
Just make sure that the thing is working as expected and starting my test directory.

4
00:00:08,570 --> 00:00:10,680
I'll make a new file of index test.

5
00:00:10,740 --> 00:00:12,580
Yes at the very top.

6
00:00:12,590 --> 00:00:16,010
I'm going to add in a couple of different imports or some things that we're definitely going to need

7
00:00:16,010 --> 00:00:17,280
inside of here.

8
00:00:17,300 --> 00:00:21,200
So first we probably need request from Super Test.

9
00:00:21,200 --> 00:00:27,770
We probably need our Express application from up to directories app and then we are probably going to

10
00:00:27,770 --> 00:00:30,550
have to create some different orders and tickets.

11
00:00:30,620 --> 00:00:34,070
So I'm going to import the order model and the ticket model as well.

12
00:00:34,970 --> 00:00:42,100
I'll get order first from up to directories models order and same thing for ticket

13
00:00:46,220 --> 00:00:48,320
I'll then write out a single test case here.

14
00:00:48,320 --> 00:00:52,100
Really just gonna do one single test where we're going to make sure that we can find a list of orders

15
00:00:52,100 --> 00:00:53,280
successfully.

16
00:00:53,420 --> 00:00:59,810
It's all put together and it's statement and I'll give it a description something like it fetches orders

17
00:01:00,050 --> 00:01:03,650
or a particular user

18
00:01:07,810 --> 00:01:11,800
testing out this row handler is going to be a little bit more complicated than it might seem at first

19
00:01:11,800 --> 00:01:12,580
glance.

20
00:01:12,730 --> 00:01:17,140
Only reason for that is that we write on a test we probably want to make sure that we only find orders

21
00:01:17,140 --> 00:01:19,990
that belong to the user who is making the request.

22
00:01:20,020 --> 00:01:24,880
In addition we're going to make sure that when we ever we get a response we also fetch and supply the

23
00:01:24,880 --> 00:01:27,100
associated ticket as well.

24
00:01:27,160 --> 00:01:29,110
So let me show you how we're gonna write out this test.

25
00:01:29,200 --> 00:01:32,340
I'm gonna write a couple of comments just to guide us as we go through it.

26
00:01:32,360 --> 00:01:36,730
So inside of here I'm going to first rate three tickets.

27
00:01:36,790 --> 00:01:39,640
They're gonna make three separate tickets say them to the database.

28
00:01:39,910 --> 00:01:44,560
We're going to create these tickets using the ticket model right here directly because remember we do

29
00:01:44,560 --> 00:01:48,490
not have any kind of request handler or anything like that inside of our app right now that we can use

30
00:01:48,490 --> 00:01:49,900
to manually create a ticket.

31
00:01:49,900 --> 00:01:52,960
The only way we can create a ticket is through the ticket model.

32
00:01:52,960 --> 00:02:03,660
After that we're then going to create one order as user number one and then create two orders as user

33
00:02:03,720 --> 00:02:05,110
number two.

34
00:02:05,130 --> 00:02:09,180
So for these three tickets we're going to create three separate orders.

35
00:02:09,180 --> 00:02:13,890
One ticket is going to be reserved by user number one and two tickets will be reserved by user number

36
00:02:13,890 --> 00:02:20,420
two we're then going to make a request and try to fetch all the different orders or specifically at

37
00:02:20,420 --> 00:02:29,420
user number two I'm going to write out a quick comment for that I'll say make requests to get orders

38
00:02:29,420 --> 00:02:34,550
for user number two and then when we get that list of orders we're going to write out an expectation

39
00:02:34,760 --> 00:02:39,560
to make sure that we got the two orders we had created right there but not the first order that we had

40
00:02:39,560 --> 00:02:42,970
created for user number one because that's really the key to this request handler.

41
00:02:43,040 --> 00:02:47,540
We want to make sure that we only fetch orders for the user who is making the request to the actual

42
00:02:47,540 --> 00:02:57,590
expectation down here is to make sure we only got the orders for user number two and the only reason

43
00:02:57,590 --> 00:03:01,130
I'm writing on all these comments is that this test is going to be pretty large in nature.

44
00:03:01,160 --> 00:03:05,120
There's a lot of code here we could definitely try to figure out some way to split this into multiple

45
00:03:05,120 --> 00:03:10,280
separate tests but I think just writing it out all inside of one test is gonna be just fine okay.

46
00:03:10,310 --> 00:03:12,000
So with all that in mind let's get to it first.

47
00:03:12,100 --> 00:03:15,560
We're gonna do is great three tickets using our ticket model.

48
00:03:15,560 --> 00:03:20,570
We could write out the ticket dot build method right here three times instead I'm going to create a

49
00:03:20,570 --> 00:03:25,080
little helper function just to make it a little bit easier and concise to create these three tickets.

50
00:03:25,400 --> 00:03:28,040
So right above the it walk I'll write out build ticket

51
00:03:32,560 --> 00:03:35,080
and then inside of here I'm going to create a ticket

52
00:03:38,020 --> 00:03:47,210
with ticket dock built I'll give it a title of concert and a price of twenty or then do and a weight

53
00:03:47,360 --> 00:03:52,470
ticket that save and then return the ticket itself.

54
00:03:52,720 --> 00:03:58,580
I'll make sure that I marked the enclosing function as a sync and now down inside of my actual test

55
00:03:58,700 --> 00:04:07,870
I can call that Bill ticket function three times so I'll do ticket 1 is a weight billed ticket and then

56
00:04:07,870 --> 00:04:14,460
copy paste that down twice and I'll change the names to ticket to and ticket three.

57
00:04:14,540 --> 00:04:14,780
All right.

58
00:04:14,780 --> 00:04:15,410
Not that bad.

59
00:04:15,410 --> 00:04:19,720
So there's our three tickets next up we're going to try to create art.

60
00:04:19,790 --> 00:04:24,320
Three different orders one as User 1 and 2 as User 2.

61
00:04:24,320 --> 00:04:28,130
We're definitely going to want to be able to make follow up requests as user number two.

62
00:04:28,340 --> 00:04:32,330
And that means that we're going to end up having to store the cookie that we get back from calling that

63
00:04:32,330 --> 00:04:38,060
global dot sign and function that we can make a follow up request as user number two later on the right

64
00:04:38,060 --> 00:04:39,370
above that first comment.

65
00:04:39,440 --> 00:04:46,000
I'll say User 1 is global dot sign and we don't actually have to make a false request as User 1.

66
00:04:46,010 --> 00:04:51,230
Nonetheless going to store this in a variable just so we can really understand where we are using each

67
00:04:51,230 --> 00:04:56,510
these different users then USER 2 will also be global signing.

68
00:04:56,930 --> 00:05:04,060
So we can very easily make requests with as either User 1 or user number 2 OK.

69
00:05:04,100 --> 00:05:10,090
So now we're going to create an order as user number one we're going to make sure that we do this making

70
00:05:10,090 --> 00:05:15,600
a request through our Express application as opposed to creating an order directly with the User model.

71
00:05:15,630 --> 00:05:20,190
The reason for that is that remember it's kind of hard for us to extract the ideas of a particular user

72
00:05:20,430 --> 00:05:23,160
directly from this cookie that we just created.

73
00:05:23,160 --> 00:05:28,340
So it's going to be a lot easier to kind of correlate the orders right here that are being created on

74
00:05:28,350 --> 00:05:29,410
with the follow up request.

75
00:05:29,430 --> 00:05:38,490
If we just use a cookie directly as opposed to creating the different orders using the order model.

76
00:05:38,560 --> 00:05:38,770
OK.

77
00:05:38,800 --> 00:05:42,200
So first we'll do it in a wait request to app.

78
00:05:42,200 --> 00:05:53,160
We're gonna do a post to API orders and we'll set our cookie to User 1 and we're gonna send along with

79
00:05:53,160 --> 00:06:01,250
this a ticket I.D. of ticket one dot I.T. and then we're going to expect to get a two a one out of that.

80
00:06:01,270 --> 00:06:06,880
So we should be able to successfully reserve ticket 1 for user 1.

81
00:06:06,890 --> 00:06:07,280
All right.

82
00:06:07,280 --> 00:06:08,730
So that's it for user number 1.

83
00:06:08,750 --> 00:06:11,760
I'm not can repeat this process twice for user number two.

84
00:06:11,870 --> 00:06:18,620
I'm going to just copy that entire block right there and then paste it down here twice then for user

85
00:06:18,620 --> 00:06:24,620
choose first request I'll make sure that I update the cookie to user to end user TOS first request is

86
00:06:24,620 --> 00:06:26,630
going to try to reserve ticket

87
00:06:30,380 --> 00:06:36,020
then on the second one will update the cookie to User 2 and in this one we're going to try to reserve

88
00:06:36,680 --> 00:06:40,910
ticket 3 like so all right.

89
00:06:40,950 --> 00:06:44,460
Now in theory our entire entire data model is complete.

90
00:06:44,460 --> 00:06:48,160
We should have everything properly associated and saved inside of our database.

91
00:06:48,160 --> 00:06:53,130
So now we can make a request to get all the orders for user number 2 and then write out some expectation

92
00:06:53,160 --> 00:06:55,620
about the data that we get back in response.

93
00:06:55,830 --> 00:07:00,560
So put inside of your accounts response is a wait request to app.

94
00:07:00,770 --> 00:07:03,210
We want to make a request to the index or handler.

95
00:07:03,230 --> 00:07:04,340
We just put together.

96
00:07:04,340 --> 00:07:07,580
So that will be a get request to API slash orders.

97
00:07:07,640 --> 00:07:14,060
We'll do a get to API orders and we really want to make sure that we make this request as specifically

98
00:07:14,120 --> 00:07:15,220
user number 2.

99
00:07:15,290 --> 00:07:18,470
So we'll set our cookie to user to

100
00:07:22,190 --> 00:07:26,510
we're going to expect to get back at two hundred and then we'll take a look at the response and make

101
00:07:26,510 --> 00:07:29,460
sure it's got the appropriate information inside of it.

102
00:07:29,560 --> 00:07:31,180
So right now.

103
00:07:31,180 --> 00:07:35,290
How about we just do a console log of response dot body and we'll figure out how to best write out some

104
00:07:35,290 --> 00:07:36,670
expectations.

105
00:07:37,090 --> 00:07:38,380
I'm going to say this.

106
00:07:38,380 --> 00:07:43,380
Let's flip back over to our terminal and see how we're doing.

107
00:07:43,450 --> 00:07:43,750
All right.

108
00:07:43,870 --> 00:07:49,240
So let's good so far I don't see any errors around the index test and I do see a console log right here

109
00:07:49,510 --> 00:07:55,030
that definitely has only 2 orders inside of it and inside of each of these orders I see the embedded

110
00:07:55,030 --> 00:07:56,350
ticket as well.

111
00:07:56,500 --> 00:08:01,070
Let's say this is off to a good start.

112
00:08:01,220 --> 00:08:06,930
Let's now go back over and let's start to write out an expectation or two so I'm going to write out

113
00:08:07,080 --> 00:08:10,080
expect response dot body to have length

114
00:08:13,020 --> 00:08:16,840
to make sure that we only got back two tickets.

115
00:08:16,850 --> 00:08:20,900
In addition we should probably make sure that the minute we got back to orders we should really make

116
00:08:20,900 --> 00:08:24,480
sure the two orders we got were the correct orders as well.

117
00:08:24,480 --> 00:08:30,500
So I going to try to save a reference to the response we get back when we create these two orders.

118
00:08:30,500 --> 00:08:35,270
So we know the I.D. of those two orders and we can write out some kind of comparison or expectation

119
00:08:35,300 --> 00:08:45,790
and make sure that we got the two correct ones so I can write out response 1 and response two.

120
00:08:46,240 --> 00:08:49,730
Now calling these responses response one in response to.

121
00:08:49,810 --> 00:08:50,180
Yeah.

122
00:08:50,190 --> 00:08:55,090
It would technically work but that's kind of confusing to see response one response to and then another

123
00:08:55,090 --> 00:08:57,010
variable down here called response.

124
00:08:57,010 --> 00:09:02,620
So instead we're going to d structure just the data we care about these responses and as we d structure

125
00:09:02,620 --> 00:09:05,020
it we're also going to rename the variable as well.

126
00:09:05,020 --> 00:09:09,940
Let me show you what I mean by the first request right here for no user number two I'm going to delete

127
00:09:10,300 --> 00:09:15,280
response one and the only thing we care about out of here is the body property right because that's

128
00:09:15,280 --> 00:09:18,150
the actual order that we're being sent back.

129
00:09:18,160 --> 00:09:22,720
Same thing on the second one as well but we cannot just have body in both cases.

130
00:09:22,720 --> 00:09:28,330
So we need to somehow restructure these things and simultaneously re name them at the same time to do

131
00:09:28,330 --> 00:09:37,440
so we're gonna put in body then a colon and then order one and order two like some.

132
00:09:37,480 --> 00:09:42,520
So this is two steps and one we are de structuring out the body property off the response we get back

133
00:09:42,520 --> 00:09:48,720
to the request and we are simultaneously renaming that body property to order one.

134
00:09:48,720 --> 00:09:53,310
So now we've got a variable of order one that we can access in the rest of this test and it's going

135
00:09:53,310 --> 00:09:55,760
to be equal to the response so we got back the body.

136
00:09:55,770 --> 00:09:58,580
The response we got back from this first request right here.

137
00:09:58,650 --> 00:10:03,900
So order one really should be well an order object and we can confirm that very easily if we just do

138
00:10:03,900 --> 00:10:10,470
a console log down here of order 1 I'm going to save the file pull it back over and I'll take a look

139
00:10:10,470 --> 00:10:17,180
at what gets console logged so Yep there we are right there that is definitely my order.

140
00:10:17,380 --> 00:10:22,330
So now we can delete that console log and write out some expectations to make sure that we got the correct

141
00:10:22,780 --> 00:10:31,850
orders back instead of response I'll do an expect response dot body at zero 1 Take a look at the idea

142
00:10:32,470 --> 00:10:36,420
and I want make sure that it's equal to order ones i.e.

143
00:10:40,980 --> 00:10:46,870
I'll then copy paste that on this next one I'll update order body to 1 and I want to make sure that

144
00:10:46,870 --> 00:10:56,470
is equal to order choose IP you're going to say that look back over and there we go everything's passing.

145
00:10:56,470 --> 00:11:01,870
All right a little bit of a longer test here but it definitely works optionally we can also take a look

146
00:11:01,870 --> 00:11:04,960
at the ticket that was embedded on both these as well.

147
00:11:04,960 --> 00:11:12,580
So if we wanted to do that we could write out an expect for response body 0 ticket i.e. it'll make sure

148
00:11:12,580 --> 00:11:13,390
that equals

149
00:11:16,140 --> 00:11:20,760
ticket to his idea and then the next will be ticket three ideas is specifically going to be ticket to

150
00:11:20,790 --> 00:11:29,040
because order 1 had a reference to ticket to so we put inside of your ticket to daddy and then I'll

151
00:11:29,040 --> 00:11:36,520
do another copy paste their updated to body at 1 make sure the second ticket inside their as an idea

152
00:11:36,550 --> 00:11:43,920
equal to ticket 3 that idea all right well let's test here so save the file pull back over and we're

153
00:11:43,920 --> 00:11:49,770
looking good as usual you might want to just make this fail just make sure all the tests are actually

154
00:11:49,770 --> 00:11:54,900
working and it's actually reloading this file properly so I'll find one of expect for the status code

155
00:11:55,050 --> 00:12:01,140
change it to a 500 rerun the test and okay.

156
00:12:01,190 --> 00:12:05,450
Definitely looks good so I'll change that back over 200 again I'm just doing that to make sure that

157
00:12:05,450 --> 00:12:10,610
the test suite is actually updating this actually properly running our test all right well that's it

158
00:12:10,610 --> 00:12:15,980
for our index root handler now I apologize for like this video could've been a little bit shorter but

159
00:12:16,100 --> 00:12:20,570
figured might as well get it all done in just one single video let's take a pause right here and we're

160
00:12:20,570 --> 00:12:22,910
gonna take a look at our next root handler in just a moment.