1 00:00:01,390 --> 00:00:05,350 I'm back inside of my test where we're going to try and check to make sure that a ticket was actually 2 00:00:05,350 --> 00:00:06,730 saved or our database. 3 00:00:06,730 --> 00:00:09,690 There's definitely a wide variety of ways we can do this. 4 00:00:09,700 --> 00:00:12,720 I think that we're gonna take a very simple simplistic approach. 5 00:00:12,730 --> 00:00:18,850 What I would like to do is first do a check and see how many records are inside of our ticket collection 6 00:00:19,410 --> 00:00:23,920 will then make the request and then after that we'll once again check to see how many records are in 7 00:00:23,920 --> 00:00:24,430 there. 8 00:00:24,430 --> 00:00:29,360 And we should see that there should be one additional record after making the request. 9 00:00:29,470 --> 00:00:31,080 So let's write out the code for this. 10 00:00:31,120 --> 00:00:35,020 I think you'll understand where we're going with it really really quickly to get started. 11 00:00:35,020 --> 00:00:39,820 I'm going to go to the top of my test file and I'm going to import that ticket model that we just created 12 00:00:40,780 --> 00:00:44,710 going to import ticket from up up models. 13 00:00:44,930 --> 00:00:45,230 Ticket 14 00:00:49,660 --> 00:00:56,800 back down at the bottom and then going to look into my tickets collection and take a look at all the 15 00:00:56,800 --> 00:00:58,770 different tickets that exist inside there. 16 00:00:58,840 --> 00:01:01,960 So I'll say let tickets is a wait. 17 00:01:01,960 --> 00:01:05,910 Ticket find with empty object. 18 00:01:05,920 --> 00:01:10,450 So this query is going to get all the different tickets that exist inside of that collection every last 19 00:01:10,450 --> 00:01:11,500 one. 20 00:01:11,500 --> 00:01:15,520 Now when I say every last one that's kind of a little misleading statement. 21 00:01:15,670 --> 00:01:21,580 You might recall that back inside of our test setup file after every single test that we run or I should 22 00:01:21,580 --> 00:01:26,080 say before every single one we take a look at all of our different collections inside of Mongo Mongo 23 00:01:26,080 --> 00:01:26,670 DB. 24 00:01:26,740 --> 00:01:29,480 And we delete all the data inside of every single one of them. 25 00:01:29,860 --> 00:01:36,370 So when this test first runs there should be zero tickets let's write out an expectation around that 26 00:01:36,370 --> 00:01:41,980 right away to just confirm there are zero tickets inside the database right now it's open and expect 27 00:01:42,550 --> 00:01:47,070 tickets not length to equal zero. 28 00:01:47,300 --> 00:01:48,760 By the way notice I'm using the like. 29 00:01:48,770 --> 00:01:49,420 You were right here. 30 00:01:49,430 --> 00:01:55,100 That's because we're going to reassign that variable right after we make the request. 31 00:01:55,180 --> 00:01:59,600 So now we make the request you might notice that we're missing a little step inside of here. 32 00:01:59,610 --> 00:02:03,990 We never actually added any check or any authentication step. 33 00:02:04,050 --> 00:02:05,670 So very similar to what we did back up here. 34 00:02:05,700 --> 00:02:14,610 Let's make sure that we set that cookie so after calling post I'll do a set cookie global sign in 35 00:02:19,530 --> 00:02:20,830 now after making the request. 36 00:02:21,330 --> 00:02:23,900 Let's take a look at all of our tickets inside that collection once again. 37 00:02:23,940 --> 00:02:30,240 And we're going to expect there to now be exactly one ticket inside there don't say tickets. 38 00:02:30,240 --> 00:02:36,000 Again that's why we use the left keyword right here so we can redefine this variable is a wait. 39 00:02:36,010 --> 00:02:46,850 Take a dot find and we should now be able to expect tickets dot length to equal one if we wanted to 40 00:02:46,850 --> 00:02:51,310 we can also take a look at the record those actually created and write out an assertion about say its 41 00:02:51,320 --> 00:02:52,760 title or its price. 42 00:02:52,760 --> 00:02:58,660 So for example we could do something like tickets at zero dot price to equal 20. 43 00:02:59,570 --> 00:03:01,370 We could do the same thing for the title as well. 44 00:03:01,370 --> 00:03:07,450 Totally up to you if you want to write in an assertion around the title I would recommend extracting 45 00:03:07,450 --> 00:03:10,450 the ticket or that title right there to a separate variable. 46 00:03:10,470 --> 00:03:19,380 That's something like Idol is blah blah blah then use that as the title and then for the actual assertion 47 00:03:19,710 --> 00:03:26,690 expect tickets zero title to equal title. 48 00:03:26,750 --> 00:03:28,790 Well that is it for our test. 49 00:03:28,870 --> 00:03:30,200 So let's save this. 50 00:03:30,200 --> 00:03:32,950 We're going to go back over to our terminal and just make sure the test is failing. 51 00:03:33,360 --> 00:03:37,190 Yep definitely is. 52 00:03:37,250 --> 00:03:40,090 Now let's go work on the actual implementation. 53 00:03:40,210 --> 00:03:44,550 I'm going to go and find my new root handler at the very top. 54 00:03:44,610 --> 00:03:51,470 I'm going to import the model that we just created so we can actually save some data so we'll go up 55 00:03:51,470 --> 00:03:53,150 one directory models. 56 00:03:53,150 --> 00:03:53,510 Ticket 57 00:03:56,690 --> 00:04:01,860 then down inside of this thing you can remove the red dots and status. 58 00:04:01,980 --> 00:04:07,380 We're going to first tried to pull off the title and the price from the body of the incoming request. 59 00:04:08,160 --> 00:04:20,420 So to pull off that data title in price from wrecked out body will then build up our ticket. 60 00:04:20,420 --> 00:04:22,250 That's gonna be ticket duck billed. 61 00:04:22,250 --> 00:04:26,090 Remember that's how we are creating records here because typescript can jump in and make sure that we're 62 00:04:26,090 --> 00:04:32,870 providing the correct structure of data that we'll put in our title we'll put in the price. 63 00:04:32,970 --> 00:04:38,000 And remember there is a third property required we have to put in the user I.D. of the person who is 64 00:04:38,000 --> 00:04:38,700 creating this ticket. 65 00:04:38,720 --> 00:04:40,670 So we know who actually owns it. 66 00:04:40,680 --> 00:04:41,370 OK. 67 00:04:41,810 --> 00:04:47,540 So we'll say that the I.D. is going to come from rec print user I.D. number. 68 00:04:47,570 --> 00:04:52,280 We have access to current user on that request object because we had previously executed our current 69 00:04:52,280 --> 00:04:54,160 user middleware back inside of app. 70 00:04:54,180 --> 00:04:55,510 Yes that thing right there. 71 00:04:55,520 --> 00:04:58,100 That's what sets the recurrent user property. 72 00:04:58,250 --> 00:05:04,310 We are getting complained out by typescript right now typescript is saying hey this I.D. thing might 73 00:05:04,310 --> 00:05:06,260 not actually be defined. 74 00:05:06,380 --> 00:05:13,520 Remember whenever we set current user we are possibly setting current user if the user is not authenticated 75 00:05:13,730 --> 00:05:17,000 then the current user Middleware is not going to set current user to anything. 76 00:05:17,000 --> 00:05:23,550 And that will be undefined right now typescript a saying hey you can't look up the property here. 77 00:05:23,560 --> 00:05:26,930 You have to make sure that the current user actually exists. 78 00:05:26,930 --> 00:05:28,840 Well we don't really have to do that. 79 00:05:28,850 --> 00:05:32,830 You might recall that or require auth middleware already does that for us. 80 00:05:32,990 --> 00:05:37,790 If I go back to the definition of the require middleware instead of our common module right here we 81 00:05:37,780 --> 00:05:42,800 are inside this middleware doing a check to make sure that current user is defined and if it's not we 82 00:05:42,800 --> 00:05:48,560 then throw this air and we never continue on to the next middleware or possibly the next request handler 83 00:05:48,560 --> 00:05:54,380 in this case so in other words right now we're never going to end up in this statement right here. 84 00:05:54,470 --> 00:06:00,080 If current user is undefined touch script just doesn't understand that because it is not looking into 85 00:06:00,080 --> 00:06:05,150 the require auth function and understanding that we're going to return early out of this entire chain 86 00:06:05,510 --> 00:06:07,740 if current user isn't defined. 87 00:06:07,790 --> 00:06:13,760 So I feel pretty comfortable adding in a exclamation to this thing and telling typescript Hey don't 88 00:06:13,760 --> 00:06:15,780 sweat it print user is defined. 89 00:06:15,860 --> 00:06:18,000 We've got this thing defined. 90 00:06:18,120 --> 00:06:24,390 Now you notice that even after that I'm still getting in air here I put in ideas right here. 91 00:06:24,390 --> 00:06:25,380 That is my mistake. 92 00:06:25,380 --> 00:06:29,040 It should be user I.D. That's better. 93 00:06:29,060 --> 00:06:30,510 So there's our ticket we've built it up. 94 00:06:30,530 --> 00:06:32,850 After that we need to actually save it. 95 00:06:33,000 --> 00:06:36,230 I'll do in a wait to get dot safe if I want to use the awake. 96 00:06:36,230 --> 00:06:37,620 You were inside of here as usual. 97 00:06:37,930 --> 00:06:45,460 Well Mark the enclosing function with async after saving that record we can now do a rez status 98 00:06:49,700 --> 00:06:59,350 to a 1 and we will send back the ticket that we just created and that should be at so let's save this 99 00:06:59,940 --> 00:07:07,600 will go back over to our terminal and all of our tests are passing fantastic Well this is pretty good. 100 00:07:07,600 --> 00:07:14,000 Now at this point you might be thinking Steven writing his tests such a pain such a pain so much extra 101 00:07:14,000 --> 00:07:14,780 stuff to go through. 102 00:07:14,810 --> 00:07:16,310 Well here's the good thing about it. 103 00:07:16,760 --> 00:07:22,150 We spent just a little bit of extra time really not that much writing out these tests and even as we 104 00:07:22,190 --> 00:07:26,930 going through that we had do a lot of extra setup stuff but we've now got a root handler and we are 105 00:07:26,930 --> 00:07:31,760 really sure that it works the way we expect without ever having to actually run our code inside the 106 00:07:31,760 --> 00:07:34,340 browser or at postmen. 107 00:07:34,340 --> 00:07:37,210 So this really is a great advantage during development. 108 00:07:37,220 --> 00:07:41,040 We do not have to be manually testing everything over and over and over again. 109 00:07:41,110 --> 00:07:47,270 And we've now got this great record right here of how this request handler should behave so we can start 110 00:07:47,270 --> 00:07:48,530 to make changes to it now. 111 00:07:48,800 --> 00:07:51,020 And if we start to break it in some particular way. 112 00:07:51,050 --> 00:07:54,110 Well we've got something to yell at us and tell us hey you're doing something wrong. 113 00:07:54,110 --> 00:07:55,330 Go fix it up. 114 00:07:55,490 --> 00:08:00,440 So if you don't like writing tests out I apologize for that but I really feel very strongly that this 115 00:08:00,440 --> 00:08:05,420 is the right thing to do when we are developing micros services because we don't have to go to the process 116 00:08:05,480 --> 00:08:09,560 of wiring this take it up to everything else inside our application where the react app or whatever 117 00:08:09,560 --> 00:08:13,650 else just to make sure that's working as expected. 118 00:08:13,750 --> 00:08:13,970 All right. 119 00:08:13,970 --> 00:08:18,500 So now that we're all done with creating a ticket we're going to take a pause right here and in the 120 00:08:18,500 --> 00:08:20,870 next video we're gonna move on to our next request handler.