1
00:00:01,210 --> 00:00:03,420
Let's move on to our three remaining tests here.

2
00:00:03,490 --> 00:00:08,380
The next one we're going to try to create a ticket and then update it with a different user that should

3
00:00:08,380 --> 00:00:10,570
return a status could afford one.

4
00:00:10,570 --> 00:00:14,830
Now this is going to be just a little bit more tricky than it might appear at first glance.

5
00:00:14,830 --> 00:00:20,500
Remember how I said that it's kind of nice to create a ticket by making an actual request to our ticket

6
00:00:20,500 --> 00:00:21,520
creation end point.

7
00:00:21,970 --> 00:00:26,920
So in other words we're going to want to write in some initial logic inside of here to create a ticket

8
00:00:27,490 --> 00:00:28,210
like this.

9
00:00:28,210 --> 00:00:37,610
We're going to want to do something that says request to at make a post to API tickets set the cookie

10
00:00:40,450 --> 00:00:51,110
with global sign in and we'll send along some title of whatever and price of about 20 that will create

11
00:00:51,110 --> 00:00:56,270
some initial ticket that we can then tried to edit and here's the key thing when we actually create

12
00:00:56,270 --> 00:01:02,750
this ticket the ticket is going to have a user I.D. equal to whatever user I.D. is extracted from the

13
00:01:02,810 --> 00:01:07,830
cookie that we include were then ideally going to want to make some kind of follow up request right

14
00:01:07,830 --> 00:01:08,130
here.

15
00:01:08,130 --> 00:01:11,290
That's going to attempt to edit this ticket that's been created.

16
00:01:11,370 --> 00:01:16,040
And when we make this follow up request we're going to try to use the same exact cookie.

17
00:01:16,050 --> 00:01:18,520
It's going to have the same user I.D. inside there.

18
00:01:18,660 --> 00:01:24,450
And so right now we only have essentially exactly one user I.D. floating around the entire application

19
00:01:24,960 --> 00:01:30,390
so we can't really fake being a different user who does not own the ticket to solve this.

20
00:01:30,390 --> 00:01:34,140
Let's go back over to our setup test file then cited my test directory.

21
00:01:34,140 --> 00:01:39,340
I'll find setup test but here's the sine function.

22
00:01:39,340 --> 00:01:41,540
And right here is where we set the I.D..

23
00:01:41,710 --> 00:01:47,140
So again that I.D. is hardcoded for every single user that we tried to authenticate as inside of our

24
00:01:47,140 --> 00:01:48,580
test environment.

25
00:01:48,580 --> 00:01:54,400
So to fix this problem up I think we should just very simply randomly generate an I.D. whenever we call

26
00:01:54,400 --> 00:01:55,190
sign it.

27
00:01:55,210 --> 00:02:00,690
So every single time we call sign in we're going to pretend we are just an entirely different user.

28
00:02:00,700 --> 00:02:05,650
Now what if we need to make the same request or make two different quests as the same user in a row.

29
00:02:05,740 --> 00:02:06,330
No problem.

30
00:02:06,370 --> 00:02:10,900
We can just call sign and once save a reference to the cookie that gets returned and then make as many

31
00:02:10,900 --> 00:02:13,040
requests as that user as we wish.

32
00:02:13,180 --> 00:02:18,910
So not the worst thing in the world to randomly generate this idea let's use that same kind of object

33
00:02:18,910 --> 00:02:23,100
I.D. thing that we saw from Mongoose that we've now used once or twice before.

34
00:02:23,350 --> 00:02:25,850
We've already imported Mongoose into this file.

35
00:02:26,170 --> 00:02:35,050
Right there we should be able to very easily replace that hardcoded I.D. with new Mongoose types object

36
00:02:35,110 --> 00:02:42,260
I.D. to X string.

37
00:02:42,310 --> 00:02:42,540
All right.

38
00:02:42,540 --> 00:02:47,250
So I should definitely work now back inside of my update test file.

39
00:02:47,310 --> 00:02:53,880
I've got one request right here that is going to attempt to rate the ticket when we make this request

40
00:02:54,240 --> 00:02:59,250
that ticket is going to be assigned some I.D. We need to capture that I.D. so that we can somehow make

41
00:02:59,280 --> 00:03:01,560
a followup request specifying the same I.D..

42
00:03:01,950 --> 00:03:08,020
So in short I'm gonna make sure that I capture the response that comes back.

43
00:03:08,090 --> 00:03:11,930
Then after that I will attempt to create another request right here.

44
00:03:11,930 --> 00:03:15,140
So another await request to app.

45
00:03:15,260 --> 00:03:17,880
This one is gonna be our actual edit request.

46
00:03:18,020 --> 00:03:24,720
So I need to make sure that when I do this put I specify using a template string.

47
00:03:24,720 --> 00:03:33,310
So back to X right there API tickets and then the idea of the ticket we had just created the response

48
00:03:34,620 --> 00:03:35,570
body.

49
00:03:38,890 --> 00:03:44,000
We're not going to pretend that we're a totally different user so we'll set our cookie and call global

50
00:03:44,010 --> 00:03:47,560
signed in a second time when we call it a second time.

51
00:03:47,560 --> 00:03:49,750
We'll now have a new randomly generated I.D..

52
00:03:50,310 --> 00:03:56,250
So as far as our app is concerned we are trying to access the thing as a different user then go ahead

53
00:03:56,280 --> 00:03:58,280
and send the update.

54
00:03:58,290 --> 00:04:02,370
I want to make now how we update this thing not super relevant.

55
00:04:02,400 --> 00:04:09,180
All we need to do here is make sure we provide some valid title and price doll put in a title of some

56
00:04:09,540 --> 00:04:13,560
new random string and some new price unity.

57
00:04:13,560 --> 00:04:17,900
We really care about here is that we get back a for one and that the update gets rejected.

58
00:04:17,900 --> 00:04:22,670
So I will expect a 4 1.

59
00:04:22,690 --> 00:04:27,460
Now one thing we could obviously do here after making this request we're only checking to see that we

60
00:04:27,460 --> 00:04:28,720
get a 4 1.

61
00:04:28,870 --> 00:04:34,300
If we had some pretty broken code we might mistakenly send back a for one and still process the update

62
00:04:34,330 --> 00:04:40,900
anyways so optionally you could do a follow up request to retrieve details about this ticket and verify

63
00:04:40,900 --> 00:04:46,500
that it has the same title and the same price just to make sure that the update was truly not processed.

64
00:04:46,570 --> 00:04:48,290
If you want to do that feel free to do so.

65
00:04:48,340 --> 00:04:49,900
Otherwise this is pretty much good for me.

66
00:04:51,290 --> 00:04:52,360
So I have to say this.

67
00:04:52,380 --> 00:04:58,100
Let's go back over to update and we'll put together our implementation tobacco over here.

68
00:04:58,150 --> 00:05:03,420
We're going to assume that if we are trying to update the ticket we hopefully have found one successfully.

69
00:05:03,450 --> 00:05:08,040
So we'll get past that if statement so after that we're going to check and make sure that whoever's

70
00:05:08,070 --> 00:05:17,430
making this request it has the same I.D. as the user I.D. it saved on the ticket will say if ticket

71
00:05:17,450 --> 00:05:32,600
dot user I.D. is not equal to wreck dot or user dot I.D. then let's throw a new not authorized air once

72
00:05:32,600 --> 00:05:37,010
again we're running to that same issue we've seen several times before where we definitely are setting

73
00:05:37,010 --> 00:05:41,930
the current user property because we've gotten past that require check what typescript doesn't really

74
00:05:41,930 --> 00:05:42,830
believe it.

75
00:05:42,830 --> 00:05:44,560
So we'll title typescript don't sweat it.

76
00:05:44,570 --> 00:05:47,610
We already made sure current user was defined inside that middleware.

77
00:05:47,690 --> 00:05:51,800
We're gonna do that by putting on that exclamation.

78
00:05:51,850 --> 00:05:52,730
So this looks good.

79
00:05:52,750 --> 00:05:54,670
Let's say this ANSI our tests are doing

80
00:05:58,030 --> 00:05:58,890
tobacco over here.

81
00:05:58,960 --> 00:06:01,230
OK everything's passing now at this point.

82
00:06:01,360 --> 00:06:03,610
We kind of never really saw that test failed.

83
00:06:03,610 --> 00:06:09,460
So for all we know writing in this implementation might not have actually made the test pass our test

84
00:06:09,460 --> 00:06:11,170
might be in itself faulty.

85
00:06:11,170 --> 00:06:15,070
So one thing I kind of like to do that we've really been neglecting in all the tests we've run out so

86
00:06:15,070 --> 00:06:16,590
far is comment.

87
00:06:16,600 --> 00:06:20,760
That's this thing out and make sure that our test actually does fail at least one time.

88
00:06:21,640 --> 00:06:22,690
So I'm going to count that out.

89
00:06:22,690 --> 00:06:28,870
I'm going to say this I got to make sure that test fails yeah definitely does.

90
00:06:28,870 --> 00:06:32,710
So we got a 200 instead of the expected for one unauthorized.

91
00:06:32,790 --> 00:06:35,800
That means that the test is working as expected.

92
00:06:35,920 --> 00:06:37,660
I'm going to uncommon that again.

93
00:06:37,660 --> 00:06:39,980
And there we go.

94
00:06:40,030 --> 00:06:41,350
So just a little bit more.

95
00:06:41,560 --> 00:06:46,000
We're going to handle the case in which we have an invalid title or price and the actual success path

96
00:06:46,060 --> 00:06:46,730
as well.

97
00:06:46,750 --> 00:06:49,120
We're gonna take care of those of both those in the next video.