1
00:00:01,460 --> 00:00:02,960
Let's move on to our next test.

2
00:00:02,960 --> 00:00:05,760
So on this one we're gonna make sure that a heir is returned.

3
00:00:05,840 --> 00:00:07,620
If the ticket is already reserved.

4
00:00:07,730 --> 00:00:09,740
So what does it mean to have a reserve ticket.

5
00:00:09,740 --> 00:00:15,410
Well as you will recall inside of our ticket model just a little bit ago we put together that is reserved

6
00:00:15,410 --> 00:00:22,230
function so we are saying that a ticket is reserved if there is an already an order inside of our database

7
00:00:22,440 --> 00:00:27,330
that has that ticket associated with it and the order has the status of created a waiting payment or

8
00:00:27,330 --> 00:00:28,520
complete.

9
00:00:28,710 --> 00:00:33,810
So in order to do a little bit of setup for this test we have to first create a ticket save it to the

10
00:00:33,810 --> 00:00:39,390
database then create an order save it to the database and make sure that the order and the ticket are

11
00:00:39,390 --> 00:00:41,380
associated with each other.

12
00:00:41,670 --> 00:00:43,760
Then we will finally make the request.

13
00:00:43,800 --> 00:00:46,890
So a little bit of setup for this test to get started.

14
00:00:46,950 --> 00:01:00,990
I will go to the top of the file and imports order from up to directories models order and ticket models.

15
00:01:01,040 --> 00:01:01,340
Ticket

16
00:01:04,370 --> 00:01:12,500
then down inside of our test we will first create a ticket and then save it to the database.

17
00:01:12,500 --> 00:01:16,760
If we forget about the different properties that a ticket requires to create one because mouse over

18
00:01:16,760 --> 00:01:22,560
the little is right there you can touch script will tell us we have to provide a title and a price that

19
00:01:22,600 --> 00:01:28,930
will put in a title of concert and a price of twenty well then go ahead and save this ticket.

20
00:01:28,930 --> 00:01:30,030
So do it in a wait.

21
00:01:30,160 --> 00:01:31,450
Ticket dot save

22
00:01:35,430 --> 00:01:41,270
then after that we'll go ahead and create our order and we win we create the order we will make sure

23
00:01:41,270 --> 00:01:48,220
that we associate this ticket and put the order in the correct state as well so we will add in order

24
00:01:49,330 --> 00:01:56,240
is ordered up built and once again if we forget what we have to provide here we can mouse over and we

25
00:01:56,240 --> 00:02:04,080
have to provide a user I.D. status expires that and ticket the ticket will be the ticket that we just

26
00:02:04,080 --> 00:02:05,350
created a moment ago.

27
00:02:05,370 --> 00:02:08,830
So I will stick in ticket like so.

28
00:02:08,880 --> 00:02:10,380
Next up a user I.D..

29
00:02:10,380 --> 00:02:11,310
Nothing special about this.

30
00:02:11,310 --> 00:02:18,100
We could just put in some random I.D. then the status and a status of this order remember is going to

31
00:02:18,100 --> 00:02:20,480
come off of our order status in them.

32
00:02:20,560 --> 00:02:24,270
So we do have to make sure we also import order status at the top of the file.

33
00:02:24,310 --> 00:02:25,390
I can go back up to the top.

34
00:02:25,420 --> 00:02:29,020
I'm going to find where we import order and I'll get order status

35
00:02:31,750 --> 00:02:32,730
and status.

36
00:02:32,800 --> 00:02:38,060
We will enter order status dot read it.

37
00:02:38,260 --> 00:02:46,920
And then finally very last property the expires at time so for expires at will put in a new date.

38
00:02:46,920 --> 00:02:52,020
Like so now if we put a new date right here that implies that the ticket or Sammy the order is going

39
00:02:52,020 --> 00:02:54,000
to expire essentially instantly.

40
00:02:54,000 --> 00:02:55,470
But that doesn't really matter.

41
00:02:55,470 --> 00:03:01,250
There's nothing inside of our reservation code right now or whether or not deciding a ticket is reserved.

42
00:03:01,290 --> 00:03:04,710
That's going to take a look at the orders expires at property.

43
00:03:04,710 --> 00:03:08,700
So we're not going to ever have our order service necessarily look at that expires that property to

44
00:03:08,700 --> 00:03:11,000
decide if this thing is expired.

45
00:03:11,040 --> 00:03:17,240
Instead we're going to always rely upon the status flag right here to decide if the order is expired.

46
00:03:17,250 --> 00:03:21,720
That might sound a bit confusing or a little bit backwards but it really comes down to how we are going

47
00:03:21,720 --> 00:03:25,010
to implement a expiration service later on in the future.

48
00:03:25,170 --> 00:03:30,900
The expiration service is going to be the thing in charge of marking in order as being expired not the

49
00:03:30,900 --> 00:03:33,510
presence of this expires at Flag.

50
00:03:33,510 --> 00:03:34,700
I know little bit confusing.

51
00:03:34,770 --> 00:03:35,490
Don't sweat it.

52
00:03:35,490 --> 00:03:39,230
We'll see what that is later on.

53
00:03:39,240 --> 00:03:39,440
All right.

54
00:03:39,450 --> 00:03:40,840
So after we create the order.

55
00:03:41,000 --> 00:03:43,780
Well then go ahead and save it to our database.

56
00:03:43,800 --> 00:03:51,070
The order dot save so now we can make our request and we should get back that status code of 400 saying

57
00:03:51,340 --> 00:03:53,500
sorry but this ticket's already been reserved.

58
00:03:54,310 --> 00:04:04,940
So put in an a wait request to at we want to make a post to API orders.

59
00:04:05,110 --> 00:04:09,820
We need to set that cookie dough cookie global dot sign in

60
00:04:13,600 --> 00:04:18,760
we will send along the idea that ticket that we are trying to reserve so ticket I.D. is ticket dot I.D.

61
00:04:21,180 --> 00:04:31,530
And then finally we will expect to get back a 400 and that should be at let's say this will back over

62
00:04:32,460 --> 00:04:34,360
and looks like we are good to go.

63
00:04:34,610 --> 00:04:38,450
And once again I don't really know if that test is failing or passing erroneously.

64
00:04:38,490 --> 00:04:43,590
So in this case I could very easily just change this expect right here and say hey we expect this to

65
00:04:43,920 --> 00:04:47,140
resolve but they for one by say that flip back over.

66
00:04:47,160 --> 00:04:52,990
No we are definitely getting correctly four hundred battery request.

67
00:04:53,350 --> 00:04:54,980
So looks good.

68
00:04:55,100 --> 00:04:56,570
All right just one more test.

69
00:04:56,570 --> 00:04:57,580
So quick pause right here.

70
00:04:57,620 --> 00:05:00,000
And the last test will really be pretty straightforward.

71
00:05:00,020 --> 00:05:01,770
It's really just going to be requests like this.

72
00:05:01,790 --> 00:05:04,460
We're gonna make sure that we get back some kind of success status code.