1 00:00:01,310 --> 00:00:04,960 Inside of our roots file we're gonna find our update dot t s file. 2 00:00:05,070 --> 00:00:07,940 This is the root handler that handles updates to tickets. 3 00:00:08,180 --> 00:00:12,830 So as I just mentioned we need to take a look at the ticket that the user is trying to update and if 4 00:00:12,830 --> 00:00:19,570 it is currently reserved or locked down we need to reject the update request to do so. 5 00:00:19,600 --> 00:00:25,160 We're gonna scroll down a little bit inside of here and then right after we find the ticket and it can 6 00:00:25,160 --> 00:00:30,290 be right before or after we take a look at who owns the ticket to somewhere inside of here we need to 7 00:00:30,290 --> 00:00:36,050 decide whether or not we should allow the ticket to be edited in case it is actually reserved. 8 00:00:36,090 --> 00:00:42,010 How about right after we find the ticket we'll say if ticket court order I.D.. 9 00:00:42,590 --> 00:00:43,700 And that's pretty much the check. 10 00:00:43,720 --> 00:00:49,150 No we had said the presence of an order I.D. means this thing is reserved and we should prevent edits. 11 00:00:49,270 --> 00:00:56,140 So if there is an order I.D. fantastic let's throw a new air I think the most appropriate air here would 12 00:00:56,140 --> 00:00:57,690 be a bad request error. 13 00:00:57,820 --> 00:01:03,110 So I'll throw a new bad Request air. 14 00:01:03,250 --> 00:01:08,590 We do have to import that at the very top from our common module I will get bad. 15 00:01:08,860 --> 00:01:14,160 Request air and that should just be about it. 16 00:01:14,250 --> 00:01:16,340 One thing we forgot we have to provide a message here. 17 00:01:16,380 --> 00:01:18,360 So some explanation. 18 00:01:18,360 --> 00:01:19,980 Well we can give a very simple explanation. 19 00:01:19,980 --> 00:01:26,940 We can say ticket is reserved or how about an edit a reserved ticket. 20 00:01:26,940 --> 00:01:30,510 Simple enough. 21 00:01:30,630 --> 00:01:31,720 ALEX Good. 22 00:01:31,730 --> 00:01:36,170 Now as I mentioned I would really like to write out a test around this as well just to make sure that 23 00:01:36,170 --> 00:01:38,810 we've got something to say yet we cannot edit a ticket. 24 00:01:38,920 --> 00:01:41,890 Naturally the logic here is really simple and straightforward. 25 00:01:41,900 --> 00:01:43,720 So the test is a little bit over the top. 26 00:01:43,730 --> 00:01:47,360 Nonetheless this is the kind of thing you want to test because this is some pretty critical business 27 00:01:47,360 --> 00:01:52,970 logic so inside of our test directory inside the Reds FOLDER WE'LL FIND update test. 28 00:01:52,970 --> 00:01:53,390 Yes 29 00:01:57,460 --> 00:02:04,150 let's then go down to the very bottom and we'll add in a new test it will say it rejects updates if 30 00:02:04,150 --> 00:02:07,600 the ticket is reserved 31 00:02:11,920 --> 00:02:15,910 let's then get a very quick reminder on how we write out tests around row handlers because it has been 32 00:02:15,910 --> 00:02:17,330 a while since we've done that. 33 00:02:17,590 --> 00:02:20,800 So I can take a look at our previous test in the previous test. 34 00:02:20,800 --> 00:02:25,810 We first created a cookie so we can make a number of requests as one consistent user. 35 00:02:25,810 --> 00:02:32,020 We then created a ticket and then made a follow up request to edit that ticket so our test is going 36 00:02:32,030 --> 00:02:37,860 to be very similar except we're going to expect the follow up edit to result in a 400 or essentially 37 00:02:37,890 --> 00:02:39,360 a bad request. 38 00:02:39,570 --> 00:02:44,250 In addition in between the creation and the update we're also going to have to reach directly into our 39 00:02:44,250 --> 00:02:48,930 database get a handle on the ticket that was created and set the order items property on that thing 40 00:02:48,930 --> 00:02:49,520 as well. 41 00:02:50,740 --> 00:02:55,960 Now just to save a little bit of time from this previous event or some previous test publishes an event 42 00:02:56,260 --> 00:03:03,750 I'm going to copy the cookie the request to create the ticket and then default request to edit it as 43 00:03:03,750 --> 00:03:03,990 well. 44 00:03:04,820 --> 00:03:10,320 So going to copy those three blocks right there and then paste them down inside of our test and we'll 45 00:03:10,320 --> 00:03:16,160 just make a couple of changes to this thing so first off we do know that our follow up request right 46 00:03:16,170 --> 00:03:22,870 here we are going to expect to get back a 400 in addition we're going to make sure that right after 47 00:03:22,870 --> 00:03:28,960 we make this initial request for the penguin to reach in find our ticket and set the order items property 48 00:03:28,960 --> 00:03:34,250 on it and to do that we're going to first off have to get access to our ticket collection. 49 00:03:34,280 --> 00:03:39,430 Number two we're also going to need access to Mongoose so we can generate a random I.D. or the order 50 00:03:39,430 --> 00:03:44,590 idea as well so at the very top looks like we've already got an import for mongoose. 51 00:03:44,610 --> 00:03:48,790 I'm going to add in an import or ticket as well from. 52 00:03:48,850 --> 00:03:53,740 Up one to models. 53 00:03:53,760 --> 00:03:54,490 Oh come on 54 00:03:59,720 --> 00:04:00,200 all right. 55 00:04:00,290 --> 00:04:07,940 Back down at our test right after we create our ticket well then do a ticket and that's going to come 56 00:04:07,940 --> 00:04:14,700 from a weight ticket defined by Idi and the idea of the ticket that we are looking for is inside the 57 00:04:14,730 --> 00:04:17,070 body of this response right here. 58 00:04:17,100 --> 00:04:20,270 So it's going to be a response not body that. 59 00:04:23,740 --> 00:04:26,980 Then we'll do a ticket set of the order. 60 00:04:27,000 --> 00:04:39,520 Idi and we're going to set it to a mongoose that types object IDI to hex string and as usual good throw 61 00:04:39,550 --> 00:04:44,640 a exclamation right after ticket right there as well. 62 00:04:44,740 --> 00:04:53,980 And then finally let's make sure we do in a weight ticket that saved and another darn exclamation. 63 00:04:53,980 --> 00:04:56,100 There we go again. 64 00:04:56,110 --> 00:04:57,310 So that's pretty much it. 65 00:04:57,340 --> 00:05:03,460 We got our consistent user rate the ticket edit it save it make the following request expect that request 66 00:05:03,460 --> 00:05:04,120 to air. 67 00:05:04,390 --> 00:05:07,010 Let's save this and see how we're doing. 68 00:05:07,040 --> 00:05:10,090 I'll go back over to my terminal and find my test suite. 69 00:05:10,160 --> 00:05:16,460 Now we are still filtering our tests so I'm going to hit W to go to the watch menu and then going to 70 00:05:16,520 --> 00:05:22,000 filter by file name once again by hitting P and I went to tried to run only this update test file. 71 00:05:22,230 --> 00:05:29,170 It's all but an update dot test case looks like I'm writing or running the correct file and it looks 72 00:05:29,170 --> 00:05:32,020 like all of our tests are passing as usual. 73 00:05:32,020 --> 00:05:35,510 Just quickly make sure this thing is failing as expected. 74 00:05:35,530 --> 00:05:40,500 So what happens if we come into all that stuff out and never set the order I.D. property. 75 00:05:40,510 --> 00:05:47,940 Well now our request should succeed with a 200 and so we got a 200 back when we were expecting a 400. 76 00:05:47,940 --> 00:05:51,270 That means that our test is failing as expected. 77 00:05:51,270 --> 00:05:55,140 So uncommon that looks like everything is going. 78 00:05:55,190 --> 00:06:02,460 Now I'll do just one last test run of all my tests inside of this project by hitting W and then a and 79 00:06:02,660 --> 00:06:06,220 we'll just make sure that the entire service is good to go. 80 00:06:06,230 --> 00:06:09,750 Yep looks like it is. 81 00:06:09,800 --> 00:06:11,270 Well that is it. 82 00:06:11,270 --> 00:06:12,550 So I think we're all set here. 83 00:06:12,560 --> 00:06:13,240 Quick pass. 84 00:06:13,280 --> 00:06:14,150 Continue in just a minute.