1
00:00:00,960 --> 00:00:04,950
We're now going to move on to our last drought handler which is going to deal with updating a ticket

2
00:00:05,420 --> 00:00:09,950
so user is going to make a request to API tickets and then the idea the ticket they're trying to update.

3
00:00:10,140 --> 00:00:14,010
That's going to be a PUT request and we're going to expect that they include the title and price that

4
00:00:14,010 --> 00:00:16,450
they want to update that ticket with.

5
00:00:16,460 --> 00:00:21,810
Now there's going to be some kind of restrictions on this handler that you would probably expect.

6
00:00:21,920 --> 00:00:26,150
In other words you're not going to be able to access this handler if you're not authenticated.

7
00:00:26,180 --> 00:00:30,370
In addition only the user who owns a ticket should be able to update it.

8
00:00:30,410 --> 00:00:33,940
You're gonna have to add in a couple of different checks to watch for those things.

9
00:00:33,950 --> 00:00:37,910
Now some of the tests that we've written out for these other handlers have been kind of simple and basic

10
00:00:37,910 --> 00:00:38,510
in nature.

11
00:00:38,600 --> 00:00:41,450
And at the end of the day were they really required.

12
00:00:41,450 --> 00:00:42,420
Maybe not.

13
00:00:42,530 --> 00:00:46,220
Maybe win a little bit overboard in testing some those other things.

14
00:00:46,220 --> 00:00:53,600
But this put test or this update one these tests are going to be super critical Not right now but later

15
00:00:53,600 --> 00:00:58,250
on INSIDE THIS PROJECT arena start to add in those other services for dealing with orders and payments

16
00:00:58,280 --> 00:00:59,210
and some other stuff.

17
00:00:59,570 --> 00:01:04,980
There's going to be some super critical logic around whether or not a user is allowed to update a ticket.

18
00:01:05,060 --> 00:01:09,200
And so having some tests in place to make sure we've written out that business logic correctly is gonna

19
00:01:09,200 --> 00:01:10,740
be very important.

20
00:01:10,740 --> 00:01:12,440
They're not going to write out those tests just yet.

21
00:01:12,440 --> 00:01:17,350
They're not going make any sense right now until we create those other services in the future I mean

22
00:01:17,350 --> 00:01:23,730
said all that let's go and put some test together for this update root handler to back inside my error

23
00:01:23,840 --> 00:01:25,380
or find the test directory.

24
00:01:25,380 --> 00:01:28,040
We'll make a new file in there of update test.

25
00:01:28,100 --> 00:01:43,130
Yes at the very top let's import requests from duper test and we'll get app from up up at after that

26
00:01:43,160 --> 00:01:44,900
let's write out some test descriptions.

27
00:01:44,900 --> 00:01:47,120
So what do we really care about here.

28
00:01:47,120 --> 00:01:51,590
Well a lot of the obvious things that we kind of carried over or implemented already four tests on these

29
00:01:51,620 --> 00:01:52,480
other routes.

30
00:01:52,550 --> 00:01:57,410
First off if a user asked for some I.D. right here that doesn't actually exist or some ticket idea that

31
00:01:57,410 --> 00:02:02,660
doesn't exist let's return a for a for if a user tries to make an update to a ticket while they're not

32
00:02:02,660 --> 00:02:03,070
logged in.

33
00:02:03,320 --> 00:02:08,310
Let's return a for one to say that is forbidden if a user tries to update a ticket they don't own.

34
00:02:08,330 --> 00:02:09,590
Let's do a far one.

35
00:02:09,620 --> 00:02:15,950
If the user doesn't provide a title or a price or a hundred invalid request and then finally if a user

36
00:02:15,950 --> 00:02:16,820
does everything right.

37
00:02:16,820 --> 00:02:20,110
So they're signed and they own the ticket and they provide a valid title and price.

38
00:02:20,150 --> 00:02:23,150
We should make sure that the actual ticket does get updated.

39
00:02:23,150 --> 00:02:26,090
So a couple of different IDs statements and total.

40
00:02:26,150 --> 00:02:32,090
So first it returns a four for if these provided I.D. does not exist

41
00:02:34,920 --> 00:02:40,200
I'm going to copy paste that down a couple of times like so and we'll just update the description for

42
00:02:40,200 --> 00:02:41,180
each of these.

43
00:02:41,230 --> 00:02:43,770
So on the next one how about returns a.

44
00:02:43,980 --> 00:02:51,760
Or a one so forbidden not allowed if the user is not authenticated on the next one.

45
00:02:51,760 --> 00:02:59,100
How about returns a for one if the user does not own the ticket after that.

46
00:02:59,100 --> 00:03:11,130
How about returns a four hundred if the user provides an invalid title or price on previous tests.

47
00:03:11,130 --> 00:03:15,520
We tried to test these things separately or in separate tests essentially this time around.

48
00:03:15,540 --> 00:03:18,470
It's going to combine all into one single test.

49
00:03:18,550 --> 00:03:23,320
I'm going to paste one more it down here and this will be our happy path so to speak.

50
00:03:23,350 --> 00:03:25,230
So the case in which everything goes right.

51
00:03:25,250 --> 00:03:34,160
They'll say it updates the ticket provided valid inputs.

52
00:03:34,190 --> 00:03:38,510
Now a lot of people out there a lot of suffer engineers have a little bit more rigorous requirements

53
00:03:38,540 --> 00:03:40,080
over descriptions than I do.

54
00:03:40,190 --> 00:03:43,160
I am really not super picky around test descriptions.

55
00:03:43,160 --> 00:03:46,790
There's definitely some people out there who are going to look at these descriptions and say it is really

56
00:03:46,790 --> 00:03:48,920
unclear what you're doing with the test.

57
00:03:48,920 --> 00:03:53,630
That's totally fine if you are someone who really feel strongly about test descriptions feel free to

58
00:03:53,630 --> 00:03:54,240
change these.

59
00:03:54,260 --> 00:03:58,490
No issue whatsoever but me personally I'm looking at these I really understand what they are trying

60
00:03:58,490 --> 00:04:06,690
to convey all right let's go ahead and have a First let's deal with the 4 0 4 so I want to make a request

61
00:04:07,210 --> 00:04:15,090
though await request to app I want to do a put to API tickets and once again we need to specify an idea

62
00:04:15,090 --> 00:04:15,990
right here.

63
00:04:15,990 --> 00:04:21,760
So once again as we saw in the last couple of videos we have to generate a valid I.D. for that we're

64
00:04:21,770 --> 00:04:26,880
going to import Mongoose at the top.

65
00:04:27,080 --> 00:04:35,910
I'll make up an idea right here so Mongoose types object I.D. And I want to make a new object I.D. specifically

66
00:04:36,580 --> 00:04:41,760
and then off that I'm going to get or invoke to hex string

67
00:04:44,520 --> 00:04:48,420
then instead of single quotes right here let's put in some back ticks.

68
00:04:48,430 --> 00:04:55,490
Now I can reference I.D. inside their along with this put requests I'm going to try to include a valid

69
00:04:55,490 --> 00:05:03,120
title to update this thing to any valid price but I'm not going to be logged in or see that I should

70
00:05:03,120 --> 00:05:03,570
be logged in.

71
00:05:03,570 --> 00:05:06,990
So let's make sure we also tag on a set cookie

72
00:05:11,370 --> 00:05:18,540
and then we will expect to get a 4 is that ticket does not exist as usual if we run this test right

73
00:05:18,570 --> 00:05:18,770
now.

74
00:05:18,780 --> 00:05:21,760
It will pass because we don't even have a root handler for the thing.

75
00:05:21,810 --> 00:05:24,550
So I won't worry about actually executing this test just yet.

76
00:05:24,570 --> 00:05:30,570
Right now let's just go ahead and fill in one or two other tests about the next one returns a for one

77
00:05:30,570 --> 00:05:32,590
at the user is not authenticated.

78
00:05:32,590 --> 00:05:41,130
So for this well we can really just copy the exact same logic we had right above pasted in and then

79
00:05:41,130 --> 00:05:45,090
instead of expecting a 4 or 4 I can expect a 4 1.

80
00:05:45,330 --> 00:05:51,920
And I want to make sure that I am not authenticated in this case.

81
00:05:51,920 --> 00:05:52,160
All right.

82
00:05:52,220 --> 00:05:57,110
So I think that's good enough to get started and to really implement any of these other tests we might

83
00:05:57,110 --> 00:06:00,780
want to try to attempt at least a little bit of implementation first.

84
00:06:00,910 --> 00:06:02,270
So let's save this.

85
00:06:02,400 --> 00:06:05,300
I'm going to pull back on my turn I'll make sure that these sets are at least running.

86
00:06:05,300 --> 00:06:07,570
Who knows how many are going to pass or fail.

87
00:06:07,730 --> 00:06:08,630
Good enough.

88
00:06:08,730 --> 00:06:09,830
So quick pause right here.

89
00:06:09,830 --> 00:06:13,850
We'll start to put together the implementation in the next video and start to fill out a couple more

90
00:06:13,850 --> 00:06:14,240
tests.