1 00:00:01,010 --> 00:00:05,700 Let's write out a quick test or two around this delete root handler inside my underscore and a score 2 00:00:05,720 --> 00:00:10,050 test directory will make a new file of delete test 2 Yes. 3 00:00:10,070 --> 00:00:21,860 Then at the very top let's get request from Super Test as usual app from up to directories app and I 4 00:00:21,860 --> 00:00:24,590 think we probably need our ticket model as well. 5 00:00:25,930 --> 00:00:32,510 Talk to directories models ticket then inside of here what do we really want to test. 6 00:00:32,510 --> 00:00:35,630 Well naturally vary so much in some of the root handlers we already tested. 7 00:00:35,630 --> 00:00:40,590 We might want to make sure that the order that the user is looking for actually exists. 8 00:00:40,590 --> 00:00:45,330 So we might want to try to send in request and try to update an order that doesn't exist at all and 9 00:00:45,330 --> 00:00:47,440 make sure we get back a form of 4. 10 00:00:47,700 --> 00:00:51,500 We could make sure that this thing is only accessible if the user is authenticated. 11 00:00:51,540 --> 00:00:55,020 We can write a test to make sure the order I.D. parameter looks valid. 12 00:00:55,740 --> 00:00:59,970 We could write out a test to make sure that the user is the owner of the order as well. 13 00:00:59,970 --> 00:01:04,020 These are all things we could definitely test but just to stay focused on what we're doing here. 14 00:01:04,020 --> 00:01:08,460 We've seen an example of all those different tests so you can copy paste them over and implement them. 15 00:01:08,490 --> 00:01:13,620 For this handler if you want to but you and I together in this video are just going to really focus 16 00:01:13,620 --> 00:01:14,910 on the success case. 17 00:01:14,910 --> 00:01:20,340 We're gonna make sure that a order can be created and then make sure that we can make a file of requests 18 00:01:20,340 --> 00:01:21,210 to delete it. 19 00:01:21,270 --> 00:01:25,970 And that's pretty much it so for the one test we're gonna write out inside of here. 20 00:01:26,050 --> 00:01:32,820 We'll give a description of it marks an order as not deleted but really cancelled. 21 00:01:38,600 --> 00:01:41,440 So I will still put in a couple of comments just to guide ourselves here. 22 00:01:41,450 --> 00:01:52,710 We're going to create a ticket with ticket model well then make a request to create an order. 23 00:01:52,930 --> 00:01:59,290 Well then make a request to cancel the order and then finally we'll write out some kind of expectation 24 00:01:59,920 --> 00:02:04,050 to make sure the thing is cancelled. 25 00:02:04,060 --> 00:02:04,660 That's pretty much it. 26 00:02:04,690 --> 00:02:07,700 So kind of another multi-stage test to put together here. 27 00:02:07,720 --> 00:02:08,980 So first off create the ticket. 28 00:02:08,980 --> 00:02:10,750 We've done this many times before. 29 00:02:10,840 --> 00:02:19,860 So a ticket dot builds with a title a price save it to the database. 30 00:02:19,860 --> 00:02:20,520 No problem. 31 00:02:21,570 --> 00:02:25,200 When we make the request to create the order and then the follow up requests you cancel the order need 32 00:02:25,200 --> 00:02:27,650 to make sure that those requests are being issued as the same user. 33 00:02:27,650 --> 00:02:30,960 So once again we'll create a single user cookie here 34 00:02:34,960 --> 00:02:37,500 and we can reuse it over both those requests. 35 00:02:37,610 --> 00:02:41,790 So first request we'll do and await request app. 36 00:02:41,960 --> 00:02:51,600 We want to do a post to create an order so that's going to be a post to API orders set are cookie send 37 00:02:51,600 --> 00:02:57,180 along the ticket i.e. or the idea that ticket to be created right up here. 38 00:02:57,280 --> 00:02:58,170 That'll be ticket. 39 00:02:58,170 --> 00:03:04,150 I.D. is ticket dot i.e. and again we'll just make sure this thing was actually created. 40 00:03:04,180 --> 00:03:09,360 So expect a 2 a 1 when we make the followup request to cancel the order. 41 00:03:09,370 --> 00:03:13,140 We need to know the idea of the order that we had just created in the previous step. 42 00:03:13,210 --> 00:03:23,090 So once again we'll d structure out the body and I'm going to rename that on the fly to a variable of 43 00:03:23,090 --> 00:03:23,820 order. 44 00:03:24,130 --> 00:03:30,160 So just using the same technique we saw a moment moments ago that's now we can try to cancel the order 45 00:03:30,780 --> 00:03:32,650 we'll do and await requests to app. 46 00:03:32,650 --> 00:03:37,710 Once again this time we're gonna make a delete request to API orders. 47 00:03:38,210 --> 00:03:39,430 Died of a string. 48 00:03:39,430 --> 00:03:40,830 We need to put the idea inside of here. 49 00:03:40,840 --> 00:03:42,790 So let's do a little bit of string templating again. 50 00:03:42,880 --> 00:03:49,200 So you some back ticks and at the end of that string we'll put in our order i.e. 51 00:03:53,210 --> 00:03:57,110 we need to make sure that we make this request has the same user so against that the cookie using the 52 00:03:57,170 --> 00:03:58,790 user that we had generated up here 53 00:04:05,990 --> 00:04:13,320 we'll send it and finally we'll expect it to A4 because that should have all worked successfully so 54 00:04:13,330 --> 00:04:17,630 having just the two a four right here could in theory be enough to say everything went. 55 00:04:17,660 --> 00:04:22,240 Expected as expected because we did get down to the bottom of this handler but once again we're not 56 00:04:22,240 --> 00:04:26,920 really writing out an expectation just yet where we actually reach into the database. 57 00:04:26,920 --> 00:04:30,740 Take a look at that order and make sure that it's order status was updated canceled. 58 00:04:30,760 --> 00:04:35,770 So again if we run this test right now it will probably pass but we could potentially have some other 59 00:04:35,770 --> 00:04:40,180 engineer come inside of here completely mess up those two lines of code and the test would still pass 60 00:04:40,720 --> 00:04:42,060 probably erroneously. 61 00:04:42,210 --> 00:04:46,660 So going to say yeah let's just go through that extra step let's try to fetch the order that had been 62 00:04:46,660 --> 00:04:48,260 created out of our database. 63 00:04:48,340 --> 00:04:53,530 We're then going to take a look at its status property and just make sure it was updated to cancelled. 64 00:04:53,530 --> 00:04:59,210 So to fetch this order out of the database or you know another way to implement this just to mention 65 00:04:59,200 --> 00:05:03,040 it really quickly we can always try to also fetch that order through the show handler that would work 66 00:05:03,040 --> 00:05:05,570 as well either way. 67 00:05:05,600 --> 00:05:06,470 Totally fine. 68 00:05:06,590 --> 00:05:13,020 Let's go with just fetching the word out of the database at the very top. 69 00:05:13,070 --> 00:05:14,790 We'll get our order in order status. 70 00:05:14,790 --> 00:05:15,230 Enum 71 00:05:20,790 --> 00:05:24,910 then back down the bottom. 72 00:05:25,140 --> 00:05:34,530 We'll get our How about we call this updated order from a weight ordered out find by I.T. and then we'll 73 00:05:34,530 --> 00:05:36,070 stick in the order. 74 00:05:41,380 --> 00:05:44,920 We're going to get back the updated order in all we really care about here is taking a look at the status 75 00:05:45,190 --> 00:05:49,170 making sure it is equal to order stored as status got cancelled that's it. 76 00:05:49,290 --> 00:05:57,610 So we can write out an expectation expect updated order status to equal order status not canceled 77 00:06:00,990 --> 00:06:07,180 and I'm getting an error right here because it is possible that update order is not defined so tell 78 00:06:07,180 --> 00:06:12,010 you what we'll use the exclamation here once again and just tell typescript Hey don't sweat it if we 79 00:06:12,010 --> 00:06:17,330 fail to actually find the order out of the database from this line right here then this line of code 80 00:06:17,330 --> 00:06:21,400 or see this line of code right here the actual expectation is going to fail because we're going to try 81 00:06:21,400 --> 00:06:26,440 to look up property status on a value of no and that will cause this test to throw an error and fail 82 00:06:27,130 --> 00:06:31,360 so it's okay here to put the exclamation because we kind of want this thing to fail if for some reason 83 00:06:31,360 --> 00:06:34,100 we fail to find the order in the database. 84 00:06:34,210 --> 00:06:38,320 So in this scenario I think it's okay to use the exclamation but if this was some actual app related 85 00:06:38,320 --> 00:06:43,000 code or code we wanted to write instead of request handler we should definitely add in a check to make 86 00:06:43,000 --> 00:06:46,090 sure that we did find in order but again in a test in setting. 87 00:06:46,360 --> 00:06:50,320 This is actually kind of what we would want to have happen we would want to see this blow up to some 88 00:06:50,320 --> 00:06:55,450 degree all right let's say this go back over to our terminal see how we're doing. 89 00:06:55,520 --> 00:07:03,880 There's my delete test right there and it looks like we are passing go now we've got this delete request 90 00:07:03,880 --> 00:07:08,980 handler all put together but there's one other thing we should probably just think about really quickly 91 00:07:09,850 --> 00:07:14,710 at some point time inside of here we are changing the status of an order that's a pretty significant 92 00:07:14,710 --> 00:07:19,600 event inside of application if there are any pending payments that we're waiting for a user to send 93 00:07:19,600 --> 00:07:25,780 over to us or if there is a pending expiration order or whatever else chances are we need to tell other 94 00:07:25,780 --> 00:07:31,430 parts of application that this order was just cancelled so in other words right after we successfully 95 00:07:31,430 --> 00:07:38,540 save this order to the database we probably should be publishing an event saying this was cancelled 96 00:07:41,460 --> 00:07:45,950 we've already got a event very similar to this back inside of our new handler where we said we're going 97 00:07:45,960 --> 00:07:50,520 to come back and take care of it of in a little bit and remember what we did to kind of have a reminder 98 00:07:50,520 --> 00:07:56,640 that we had to update that new request handler we put in one of those X it tests inside of our test 99 00:07:56,640 --> 00:08:01,590 file or me it was a to do test we made the to do test to say oh there's something we still had to come 100 00:08:01,590 --> 00:08:03,570 back and take care of let's do the same. 101 00:08:03,570 --> 00:08:10,480 In this case as well in our delete test file I'm going to go down to the bottom and I'll say it emits 102 00:08:10,720 --> 00:08:19,160 a order canceled event and I going to mark that as it dot to do and so that's going to be kind of our 103 00:08:19,160 --> 00:08:23,670 sign here something just remind us we do have to come back and take care of something inside of here. 104 00:08:23,720 --> 00:08:29,890 So I should see that we have two pending to DOS or those two different events so we still need to implement. 105 00:08:30,090 --> 00:08:30,360 All right. 106 00:08:30,390 --> 00:08:33,840 That's pretty much it for our basic root handlers. 107 00:08:33,840 --> 00:08:36,140 We've got our four different handlers. 108 00:08:36,330 --> 00:08:39,870 We have not really tested these inside the browser they're not hooked up to the react app or anything 109 00:08:39,870 --> 00:08:44,220 like that but because we have our test suite running I'm pretty confident that everything is going to 110 00:08:44,220 --> 00:08:45,820 work as expected. 111 00:08:45,840 --> 00:08:51,210 So at this point the next thing we really have to do is think about events inside the service remember 112 00:08:51,270 --> 00:08:55,950 events inside of our order service are going to be very tightly couple to a degree as tightly coupled 113 00:08:55,950 --> 00:08:58,410 as events are over to our ticket service. 114 00:08:58,440 --> 00:09:03,210 So we really need to get a good understanding of how these two services are communicating and the exact 115 00:09:03,210 --> 00:09:06,000 events that are going to be shared between the two. 116 00:09:06,000 --> 00:09:10,680 So let's start to take a look a deeper look at all this the venting stuff inside of our particular application 117 00:09:10,710 --> 00:09:11,400 in just a moment.