1
00:00:01,460 --> 00:00:02,780
Time for our very last test.

2
00:00:02,780 --> 00:00:07,310
So we're gonna make sure that we have the ability to successfully reserve a ticket inside this test.

3
00:00:07,310 --> 00:00:09,530
We do still have to do a little bit of setup.

4
00:00:09,530 --> 00:00:14,090
We need to make sure that there is a ticket inside the database that is free and not reserved.

5
00:00:14,090 --> 00:00:17,960
So we're going to first create a ticket save it to the database and then make a request and attempt

6
00:00:17,960 --> 00:00:19,590
to reserve it.

7
00:00:19,700 --> 00:00:24,080
So we'll first create a ticket with our ticket duck billed.

8
00:00:24,430 --> 00:00:29,480
We'll give this the title of concert in a price of twenty and then we can save that ticket

9
00:00:34,570 --> 00:00:35,650
after the ticket has been saved.

10
00:00:35,650 --> 00:00:37,690
We can then make a request and attempt to reserve it.

11
00:00:37,750 --> 00:00:41,280
So it will be a request vary so much what we wrote just a moment ago.

12
00:00:41,280 --> 00:00:47,530
The only difference is we will expect to get back a status code of 2 0 1 which indicates that the order

13
00:00:47,530 --> 00:00:57,610
has actually been created they will do and await request to at you want to make a post to API orders

14
00:01:00,030 --> 00:01:00,900
not send just yet.

15
00:01:00,900 --> 00:01:01,730
We want to set.

16
00:01:01,740 --> 00:01:02,430
That's better.

17
00:01:02,460 --> 00:01:09,460
Set our cookie to global that sign in just to make sure we are authenticated then we can send along

18
00:01:09,520 --> 00:01:19,530
the ticket idea so ticket I.D. is that tickets I.D. so we'll make sure we put in ticket dot I.D. And

19
00:01:19,530 --> 00:01:25,330
then finally we will expect this to resolved with a two a one indicating that the order was created.

20
00:01:25,430 --> 00:01:31,490
So let's save that go back over to our terminal and it looks like it is passing just to make sure it

21
00:01:31,490 --> 00:01:32,870
is passing for the correct reasons.

22
00:01:32,870 --> 00:01:38,960
I will flip back over change that expectation to a four hundred just to make sure that if we have an

23
00:01:38,990 --> 00:01:42,440
incorrect expectation here the test does fail and yet looks good.

24
00:01:42,440 --> 00:01:47,240
So we expected a 400 but we actually got a two a one which means that the ticket was actually saved

25
00:01:47,480 --> 00:01:52,850
in theory to the database successfully we can change that back to two a one and we should be at green

26
00:01:52,880 --> 00:01:55,050
again.

27
00:01:55,350 --> 00:01:58,520
Now naturally we could kind of do a follow up on this test right here.

28
00:01:58,530 --> 00:02:02,710
We could tried to write out something it says hey let's reach into the order collection.

29
00:02:02,730 --> 00:02:04,700
Make sure there are no orders inside there.

30
00:02:04,740 --> 00:02:09,300
And then after making the request take another look at the order collection and assert that there is

31
00:02:09,300 --> 00:02:16,590
at least one order inside our request handler right here actually does send the order as well so we

32
00:02:16,590 --> 00:02:19,560
could potentially also get the response back.

33
00:02:19,560 --> 00:02:23,610
Take a look at the order that was created and attempt to find it inside of our order collection.

34
00:02:23,610 --> 00:02:27,600
So a lot of different ways we can improve upon this to make sure that the order truly is safe to the

35
00:02:27,600 --> 00:02:28,450
database.

36
00:02:28,500 --> 00:02:32,470
But again right now a two a one is kind of good enough for me.

37
00:02:32,580 --> 00:02:36,900
I've got a reasonable degree of certainty that if I get down to this line of code I've successfully

38
00:02:36,900 --> 00:02:39,200
executed the safe.

39
00:02:39,270 --> 00:02:44,040
But again we might end up coming back and changing this code in the future and some other engineer might

40
00:02:44,100 --> 00:02:45,870
accidently do that right there.

41
00:02:45,870 --> 00:02:51,460
They might come in out everything and then maybe remove sending back the order.

42
00:02:51,510 --> 00:02:56,130
So if we save this our orders mean our test was still passed successfully even though our code is definitely

43
00:02:56,130 --> 00:02:57,840
not doing the right thing.

44
00:02:58,500 --> 00:03:02,100
So if you want to you could definitely add in that extra little check to make sure that everything truly

45
00:03:02,100 --> 00:03:03,530
is working as expected.

46
00:03:03,570 --> 00:03:05,950
But right now I think this is good enough for me.

47
00:03:05,970 --> 00:03:08,690
Just we don't spend a ton of time writing tests yet.

48
00:03:08,780 --> 00:03:11,930
So that's it for tests around our new root handler.

49
00:03:11,960 --> 00:03:16,610
Now I want to point out once again I know writing tests is sometimes a little bit of a pain but it was

50
00:03:16,610 --> 00:03:19,280
super critical to do in this case.

51
00:03:19,280 --> 00:03:24,590
Right now we don't really have any way of manually testing our order service and any kind of development

52
00:03:24,620 --> 00:03:30,450
environment the orders service itself doesn't have any functionality tied to it for creating a ticket.

53
00:03:30,530 --> 00:03:36,110
We don't have any way to somehow load up a order or severe ticket into the order service.

54
00:03:36,110 --> 00:03:41,210
And so we would have not been able to make sure that the order could somehow reserve a ticket successfully

55
00:03:41,660 --> 00:03:45,770
if we launch this thing inside of our communities cluster right now and started sending requests to

56
00:03:45,770 --> 00:03:46,600
it through postman.

57
00:03:47,030 --> 00:03:51,040
So this really is a scenario we're writing out some tests is strictly mandatory.

58
00:03:51,050 --> 00:03:58,060
It has to be done as we just otherwise don't know if this root handler is working as expected.

59
00:03:58,110 --> 00:03:58,320
All right.

60
00:03:58,350 --> 00:04:04,050
Now we've got this but together we still do have to take care of some event related stuff and we still

61
00:04:04,050 --> 00:04:06,290
got a couple of other root handlers to get through.

62
00:04:06,300 --> 00:04:08,750
So as usual quick pause come back in just a moment.