1 00:00:00,180 --> 00:00:05,100 In this lesson you're going to learn how to make more advanced assertions in your test cases. 2 00:00:05,100 --> 00:00:12,780 Currently all of our test cases make an assertion about the H TTP response status code and that is a 3 00:00:12,780 --> 00:00:14,450 great place to get started. 4 00:00:14,700 --> 00:00:20,370 But in this lesson we're going to explore some more advanced things we can assert after the request 5 00:00:20,370 --> 00:00:21,410 is complete. 6 00:00:21,420 --> 00:00:27,630 For example we can assert things about the response body and we can also peek into the database to make 7 00:00:27,630 --> 00:00:29,360 sure everything looks correct. 8 00:00:29,370 --> 00:00:33,120 They're based off of the operation we performed to start. 9 00:00:33,180 --> 00:00:40,050 If we want to get access to the response from super test only have to do is create a variable so something 10 00:00:40,050 --> 00:00:41,710 like a constant response. 11 00:00:41,820 --> 00:00:45,530 And we are going to await the promised sitting right here. 12 00:00:45,570 --> 00:00:49,530 So this is going to store the response in the response variable. 13 00:00:49,530 --> 00:00:55,980 And for us that's useful because this contains amongst other things the response body so we can take 14 00:00:55,980 --> 00:01:02,370 a look at the user profile we got back as well as the authentication token and make sure everything 15 00:01:02,520 --> 00:01:04,380 is what we would expect. 16 00:01:04,440 --> 00:01:09,450 Now we can go ahead and do a lot of things with this information and I want to give you just a few ideas 17 00:01:09,450 --> 00:01:10,830 of what you could do. 18 00:01:11,100 --> 00:01:16,950 So the goal in this section is to just give you some tools that are gonna make it possible to test in 19 00:01:17,010 --> 00:01:18,060 the future. 20 00:01:18,060 --> 00:01:23,370 So here's a few ideas for things you could test one you could go ahead and try to fetch that user from 21 00:01:23,370 --> 00:01:24,060 the database. 22 00:01:24,060 --> 00:01:31,070 So right here assert that the database was changed correctly. 23 00:01:31,110 --> 00:01:37,410 Now in this case that would mean that there is a new user with the same I.D. as the I.D. We're getting 24 00:01:37,410 --> 00:01:41,820 back as part of the response body so we could go ahead and do just that. 25 00:01:42,450 --> 00:01:45,740 Let's create a constant user and we will use the following. 26 00:01:45,750 --> 00:01:46,390 I'll wait. 27 00:01:46,390 --> 00:01:48,630 Something we've used plenty of times before. 28 00:01:48,630 --> 00:01:57,150 User dot find by I.D. Now the I.D. for this user should have come back on that response body. 29 00:01:57,150 --> 00:02:00,310 So that is response dot body. 30 00:02:00,330 --> 00:02:03,800 Remember we have user and token as the properties that come back. 31 00:02:03,810 --> 00:02:07,830 We want user then dot underscore I.D.. 32 00:02:07,830 --> 00:02:13,620 So here we're trying to extract that user from the database and then we can go ahead and assert all 33 00:02:13,620 --> 00:02:14,490 sorts of things. 34 00:02:14,490 --> 00:02:21,240 For example I can assert that I actually do get a user back so I'll make sure that the user variable 35 00:02:21,300 --> 00:02:25,350 right here is indeed what we would have expected something like an object. 36 00:02:25,350 --> 00:02:30,860 Now we know that if there is no user with this I.D. user is going to be null. 37 00:02:30,900 --> 00:02:35,460 So down below we can use expect to make sure that it is not null. 38 00:02:35,460 --> 00:02:39,980 I'm going to expect that the user is not null now. 39 00:02:39,990 --> 00:02:42,420 So far we've only ever used to be. 40 00:02:42,420 --> 00:02:47,560 But there's also to be null This checks if something is null. 41 00:02:47,560 --> 00:02:49,850 Now we want the exact opposite of that. 42 00:02:49,860 --> 00:02:56,490 I want to make sure it's not null and there's a property we can change on to reverse our assertion. 43 00:02:56,490 --> 00:03:01,450 So right here right after we call expect before dot to be null. 44 00:03:01,470 --> 00:03:03,690 We will use dot not. 45 00:03:03,810 --> 00:03:07,370 So here I am expecting the user not to be. 46 00:03:07,500 --> 00:03:08,400 No. 47 00:03:08,400 --> 00:03:13,710 Now we can use the expect documentation to view all of this in detail it's the exact same place we looked 48 00:03:13,710 --> 00:03:19,050 at before over here down below we have expect with examples on how to cover all of this. 49 00:03:19,050 --> 00:03:21,660 And the other assertions available to you. 50 00:03:21,870 --> 00:03:29,310 But this one now just confirms that when we do sign up the user we get our 2 0 1 and that user is actually 51 00:03:29,310 --> 00:03:31,740 saved to the database. 52 00:03:31,740 --> 00:03:36,900 Now if I go ahead and rerun the test case I would expect that it runs successfully. 53 00:03:36,900 --> 00:03:41,800 Now we're not adding any new test cases we're just refining our existing ones. 54 00:03:41,880 --> 00:03:45,870 And right here we still have 13 passing tests. 55 00:03:45,870 --> 00:03:51,960 Next up let's look at how we can assert things about the response body so that can also be useful when 56 00:03:51,960 --> 00:03:58,320 writing test cases making sure that the response body matches up with what you were expecting right 57 00:03:58,320 --> 00:04:06,570 here assertions about the response and let's say for example I want to assert that the response body 58 00:04:06,570 --> 00:04:10,480 does contain the name for the user Andrew. 59 00:04:10,590 --> 00:04:16,140 Now you could also assert that the user in the database has that name but doing both would probably 60 00:04:16,140 --> 00:04:17,760 be overkill. 61 00:04:17,790 --> 00:04:19,890 Let's go ahead and start using expect. 62 00:04:19,890 --> 00:04:26,090 So I'm going to expect we have response dot body which contains that response body. 63 00:04:26,220 --> 00:04:33,420 Then we have user dot name which is where the name lives and I could expect that to equal using to be 64 00:04:33,480 --> 00:04:35,050 the following these string. 65 00:04:35,070 --> 00:04:42,540 Andrew now this is going to require us to type and expect assertion for every property we want to test. 66 00:04:42,540 --> 00:04:49,020 Now if we just have to test one this would work perfectly fine but expect has a Another assertion we 67 00:04:49,020 --> 00:04:51,710 can use when we're working with objects. 68 00:04:51,720 --> 00:04:53,440 So let's explore that. 69 00:04:53,490 --> 00:04:57,890 I'm gonna remove the current expect call and replace it with a new one. 70 00:04:58,020 --> 00:05:03,810 This time we're going to expect something about the response body in general and what we're going to 71 00:05:03,810 --> 00:05:13,770 do is use to match object to match object allows us to provide an object and response not in body needs 72 00:05:13,770 --> 00:05:18,840 to at least contain the properties we outlined with the values we specified. 73 00:05:18,840 --> 00:05:24,710 It's OK if it has extra ones but the ones we list out do need to match up exactly. 74 00:05:24,780 --> 00:05:32,080 So as an example once again I can assert something about the user checking that name equals Andrew. 75 00:05:32,130 --> 00:05:35,550 So this is identical to what we had earlier. 76 00:05:35,550 --> 00:05:40,590 Now the nice thing about this solution is that if I want to assert about other properties I can simply 77 00:05:40,590 --> 00:05:41,580 add them right on. 78 00:05:41,580 --> 00:05:48,870 For example the email should equal Andrew at example dot com and I could also assert that the token 79 00:05:48,870 --> 00:05:52,340 we got back is the tokens stored in the database. 80 00:05:52,350 --> 00:05:55,340 So right here we can take a look at how to get that done. 81 00:05:55,530 --> 00:06:01,800 I'm going to assert something about the token in the response and I'll make sure that it lives on the 82 00:06:01,800 --> 00:06:05,360 user profile on their tokens array. 83 00:06:05,400 --> 00:06:11,610 That person should only have one token so I'll grab it by index and we'll grab the token field. 84 00:06:11,610 --> 00:06:17,700 So this is asserting something about the user's name the user's email and the token we get back. 85 00:06:17,700 --> 00:06:23,640 Now once again it might not make sense depending on your particular test case to test things about the 86 00:06:23,640 --> 00:06:24,930 response body. 87 00:06:24,930 --> 00:06:29,770 The goal here though is to give you all of the tools in case that's something you need to do. 88 00:06:29,820 --> 00:06:36,300 Now we can go ahead and save our user test suite and the test case will rerun down below and we should 89 00:06:36,300 --> 00:06:42,900 still have 13 passing tests and that is exactly what we're getting now as an example of one more thing 90 00:06:42,900 --> 00:06:49,350 you could choose to test you could make sure that the plain text password is not stored in the database. 91 00:06:49,380 --> 00:06:56,520 So right here I fetched the user from the database and I will expect something about the user password 92 00:06:57,240 --> 00:07:03,870 here I'm going to use not once again with to be something we've used plenty of times before and I'm 93 00:07:03,870 --> 00:07:11,240 going to expect the password to not be the plain text password up above that is my pass. 94 00:07:11,250 --> 00:07:14,360 7 7 7 exclamation mark. 95 00:07:14,370 --> 00:07:20,640 So with this in place we've tested some pretty good things related to signing up a user we've asserted 96 00:07:20,640 --> 00:07:25,630 they were saved and we asserted things about the response and what's stored in the database. 97 00:07:25,650 --> 00:07:30,660 Now when it comes to writing tests it can be confusing at first to figure out what you're supposed to 98 00:07:30,660 --> 00:07:36,480 make assertions about and the reason it can be confusing is because you can easily go overboard really 99 00:07:36,480 --> 00:07:37,320 quickly. 100 00:07:37,440 --> 00:07:43,290 As an example I might say that I'm concerned that when a user signs up all other users are actually 101 00:07:43,290 --> 00:07:44,370 getting deleted. 102 00:07:44,460 --> 00:07:46,460 That's so unlikely to happen. 103 00:07:46,530 --> 00:07:52,210 But I could indeed write some code in this test case to verify that never happens. 104 00:07:52,230 --> 00:07:58,470 Now that's going to make all my test cases a mile long and more useless than helpful in this case. 105 00:07:58,470 --> 00:08:03,150 We want to make sure that our assertions are grounded in what could actually go wrong. 106 00:08:03,210 --> 00:08:06,600 And in this case I think we've done a really good job at that. 107 00:08:06,600 --> 00:08:11,130 So now what I'd like to do is talk about a couple of the other test cases that we'll be making some 108 00:08:11,130 --> 00:08:14,610 changes too and that'll be your challenge for the video. 109 00:08:14,640 --> 00:08:17,910 So down below we're going to start with this one right here. 110 00:08:17,910 --> 00:08:20,310 Should log in existing users. 111 00:08:20,310 --> 00:08:26,200 So this is where they provide the correct credentials and we get our 200 response back. 112 00:08:26,230 --> 00:08:32,670 Right here it is your challenge to do the following validate the new token created when the user logs 113 00:08:32,670 --> 00:08:35,990 in is actually saved to the database. 114 00:08:36,000 --> 00:08:39,350 So right here you're going to fetch the user from the database. 115 00:08:39,450 --> 00:08:45,870 You're then going to assert that the token in the response body matches up with the users second token 116 00:08:45,870 --> 00:08:51,000 in the database and finally you'll save the test case to test your work. 117 00:08:51,000 --> 00:08:56,600 Now once again you're modifying this existing test case not creating a new one. 118 00:08:56,610 --> 00:08:58,680 Now why these second token. 119 00:08:58,680 --> 00:09:05,690 Well the user were logging in as is our test user up above when we created them we already created them 120 00:09:05,690 --> 00:09:06,840 with a token. 121 00:09:06,920 --> 00:09:11,290 So if they were to log in the new token would be added onto the array. 122 00:09:11,300 --> 00:09:13,000 Being the second one. 123 00:09:13,310 --> 00:09:14,030 So down below. 124 00:09:14,030 --> 00:09:15,400 This is what I'd like you to do. 125 00:09:15,410 --> 00:09:20,840 Take some time to knock that out test your work and when you're done come back and click play. 126 00:09:24,640 --> 00:09:25,390 How'd that go. 127 00:09:25,390 --> 00:09:26,260 Let's get to it. 128 00:09:26,260 --> 00:09:30,010 The first thing I'm going to do is create a response variable. 129 00:09:30,040 --> 00:09:31,330 We'll start there. 130 00:09:31,330 --> 00:09:34,710 Then we'll actually go ahead and fetch the user from the database. 131 00:09:34,720 --> 00:09:36,670 So const user equals. 132 00:09:36,910 --> 00:09:45,040 I'll be using a wait with the user defined by I.D. and the idea is stored in user 1 I.D. defined earlier 133 00:09:45,040 --> 00:09:46,480 in this file. 134 00:09:46,510 --> 00:09:52,420 Now from here we want to go ahead and make our assertions so I can use expect I am expecting something 135 00:09:52,420 --> 00:09:54,390 about the token in the response. 136 00:09:54,400 --> 00:09:58,660 So response dot body dot token. 137 00:09:58,750 --> 00:10:04,540 And in this case I want to make sure it matches up with the token stored on the user's profile so I 138 00:10:04,540 --> 00:10:07,680 can use it to be to compare the two things. 139 00:10:07,690 --> 00:10:12,010 And here we are looking for user dot tokens. 140 00:10:12,010 --> 00:10:18,670 We're trying to grab the second one so that is the index of one followed by dot token at the property 141 00:10:18,820 --> 00:10:21,400 where the JWT is stored. 142 00:10:21,400 --> 00:10:28,660 Now with this in place I should be able to test my work and get a once again 13 out of 13 passing test 143 00:10:28,660 --> 00:10:34,570 response down below I can save the user test suite and is rerunning and down below. 144 00:10:34,570 --> 00:10:37,230 Everything is passing which is great. 145 00:10:37,330 --> 00:10:43,210 Now there's just one more test case I want to take a quick moment to modify down here we have it you 146 00:10:43,220 --> 00:10:46,090 should delete account for user. 147 00:10:46,090 --> 00:10:51,320 Once again it's gonna be your job to make some changes to this test case. 148 00:10:51,370 --> 00:10:56,020 Your goal is to validate that that user is actually removed. 149 00:10:56,020 --> 00:11:01,930 So you're gonna try to fetch the test user from the database and this time you're going to assert that 150 00:11:01,930 --> 00:11:04,730 you do indeed get null back. 151 00:11:04,750 --> 00:11:11,080 You should not be able to find the user because they should have been deleted and you can use that same 152 00:11:11,080 --> 00:11:15,890 assertion we explored earlier in this video to check if something was null. 153 00:11:15,910 --> 00:11:21,590 That was up above in the sign up test and finally you're gonna go ahead and test your work. 154 00:11:21,730 --> 00:11:28,060 So take some time to add those changes to the test case below when you're done come back and click play 155 00:11:32,100 --> 00:11:32,760 all right. 156 00:11:32,760 --> 00:11:33,570 How'd that go. 157 00:11:33,570 --> 00:11:38,060 Let's go ahead and kick things off once again by just getting the response. 158 00:11:38,100 --> 00:11:42,990 Actually for this one we don't need the response so we'll leave that off right here. 159 00:11:42,990 --> 00:11:46,960 We'll start by fetching the user const user equals. 160 00:11:47,190 --> 00:11:54,330 I'm going to use a wait with user dot find by I.D. once again and I'm trying to find the user we had 161 00:11:54,330 --> 00:12:01,020 created because that's the one we had logged in as when we deleted the user profile and right here oh 162 00:12:01,020 --> 00:12:06,030 we're going to do is assert that user is now no we should not have found a match. 163 00:12:06,150 --> 00:12:10,890 So I'm going to expect that user equals using to be. 164 00:12:10,890 --> 00:12:12,300 No no. 165 00:12:12,300 --> 00:12:14,500 And right here we're all done. 166 00:12:14,520 --> 00:12:20,850 So now we can go ahead and remove those challenge comments save the file for the last time in this video 167 00:12:21,120 --> 00:12:27,630 and right here we should still see those 13 passing tests and that is exactly what we're getting. 168 00:12:27,630 --> 00:12:33,810 So making these super test request is a great place to get started but depending on the test case you 169 00:12:33,810 --> 00:12:39,750 can take it to the next level by looking at the response or looking in the database to make sure things 170 00:12:39,750 --> 00:12:42,320 have changed as you expected. 171 00:12:42,330 --> 00:12:47,400 Now that we have some more advanced assertion techniques in our tool box we're going to continue on 172 00:12:47,460 --> 00:12:48,420 to the next lesson.