In this lesson you're going to learn how to make more advanced assertions in your test cases.
Currently all of our test cases make an assertion about the H TTP response status code and that is a
great place to get started.
But in this lesson we're going to explore some more advanced things we can assert after the request
is complete.
For example we can assert things about the response body and we can also peek into the database to make
sure everything looks correct.
They're based off of the operation we performed to start.
If we want to get access to the response from super test only have to do is create a variable so something
like a constant response.
And we are going to await the promised sitting right here.
So this is going to store the response in the response variable.
And for us that's useful because this contains amongst other things the response body so we can take
a look at the user profile we got back as well as the authentication token and make sure everything
is what we would expect.
Now we can go ahead and do a lot of things with this information and I want to give you just a few ideas
of what you could do.
So the goal in this section is to just give you some tools that are gonna make it possible to test in
the future.
So here's a few ideas for things you could test one you could go ahead and try to fetch that user from
the database.
So right here assert that the database was changed correctly.
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
back as part of the response body so we could go ahead and do just that.
Let's create a constant user and we will use the following.
I'll wait.
Something we've used plenty of times before.
User dot find by I.D. Now the I.D. for this user should have come back on that response body.
So that is response dot body.
Remember we have user and token as the properties that come back.
We want user then dot underscore I.D..
So here we're trying to extract that user from the database and then we can go ahead and assert all
sorts of things.
For example I can assert that I actually do get a user back so I'll make sure that the user variable
right here is indeed what we would have expected something like an object.
Now we know that if there is no user with this I.D. user is going to be null.
So down below we can use expect to make sure that it is not null.
I'm going to expect that the user is not null now.
So far we've only ever used to be.
But there's also to be null This checks if something is null.
Now we want the exact opposite of that.
I want to make sure it's not null and there's a property we can change on to reverse our assertion.
So right here right after we call expect before dot to be null.
We will use dot not.
So here I am expecting the user not to be.
No.
Now we can use the expect documentation to view all of this in detail it's the exact same place we looked
at before over here down below we have expect with examples on how to cover all of this.
And the other assertions available to you.
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
saved to the database.
Now if I go ahead and rerun the test case I would expect that it runs successfully.
Now we're not adding any new test cases we're just refining our existing ones.
And right here we still have 13 passing tests.
Next up let's look at how we can assert things about the response body so that can also be useful when
writing test cases making sure that the response body matches up with what you were expecting right
here assertions about the response and let's say for example I want to assert that the response body
does contain the name for the user Andrew.
Now you could also assert that the user in the database has that name but doing both would probably
be overkill.
Let's go ahead and start using expect.
So I'm going to expect we have response dot body which contains that response body.
Then we have user dot name which is where the name lives and I could expect that to equal using to be
the following these string.
Andrew now this is going to require us to type and expect assertion for every property we want to test.
Now if we just have to test one this would work perfectly fine but expect has a Another assertion we
can use when we're working with objects.
So let's explore that.
I'm gonna remove the current expect call and replace it with a new one.
This time we're going to expect something about the response body in general and what we're going to
do is use to match object to match object allows us to provide an object and response not in body needs
to at least contain the properties we outlined with the values we specified.
It's OK if it has extra ones but the ones we list out do need to match up exactly.
So as an example once again I can assert something about the user checking that name equals Andrew.
So this is identical to what we had earlier.
Now the nice thing about this solution is that if I want to assert about other properties I can simply
add them right on.
For example the email should equal Andrew at example dot com and I could also assert that the token
we got back is the tokens stored in the database.
So right here we can take a look at how to get that done.
I'm going to assert something about the token in the response and I'll make sure that it lives on the
user profile on their tokens array.
That person should only have one token so I'll grab it by index and we'll grab the token field.
So this is asserting something about the user's name the user's email and the token we get back.
Now once again it might not make sense depending on your particular test case to test things about the
response body.
The goal here though is to give you all of the tools in case that's something you need to do.
Now we can go ahead and save our user test suite and the test case will rerun down below and we should
still have 13 passing tests and that is exactly what we're getting now as an example of one more thing
you could choose to test you could make sure that the plain text password is not stored in the database.
So right here I fetched the user from the database and I will expect something about the user password
here I'm going to use not once again with to be something we've used plenty of times before and I'm
going to expect the password to not be the plain text password up above that is my pass.
7 7 7 exclamation mark.
So with this in place we've tested some pretty good things related to signing up a user we've asserted
they were saved and we asserted things about the response and what's stored in the database.
Now when it comes to writing tests it can be confusing at first to figure out what you're supposed to
make assertions about and the reason it can be confusing is because you can easily go overboard really
quickly.
As an example I might say that I'm concerned that when a user signs up all other users are actually
getting deleted.
That's so unlikely to happen.
But I could indeed write some code in this test case to verify that never happens.
Now that's going to make all my test cases a mile long and more useless than helpful in this case.
We want to make sure that our assertions are grounded in what could actually go wrong.
And in this case I think we've done a really good job at that.
So now what I'd like to do is talk about a couple of the other test cases that we'll be making some
changes too and that'll be your challenge for the video.
So down below we're going to start with this one right here.
Should log in existing users.
So this is where they provide the correct credentials and we get our 200 response back.
Right here it is your challenge to do the following validate the new token created when the user logs
in is actually saved to the database.
So right here you're going to fetch the user from the database.
You're then going to assert that the token in the response body matches up with the users second token
in the database and finally you'll save the test case to test your work.
Now once again you're modifying this existing test case not creating a new one.
Now why these second token.
Well the user were logging in as is our test user up above when we created them we already created them
with a token.
So if they were to log in the new token would be added onto the array.
Being the second one.
So down below.
This is what I'd like you to do.
Take some time to knock that out test your work and when you're done come back and click play.
How'd that go.
Let's get to it.
The first thing I'm going to do is create a response variable.
We'll start there.
Then we'll actually go ahead and fetch the user from the database.
So const user equals.
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
in this file.
Now from here we want to go ahead and make our assertions so I can use expect I am expecting something
about the token in the response.
So response dot body dot token.
And in this case I want to make sure it matches up with the token stored on the user's profile so I
can use it to be to compare the two things.
And here we are looking for user dot tokens.
We're trying to grab the second one so that is the index of one followed by dot token at the property
where the JWT is stored.
Now with this in place I should be able to test my work and get a once again 13 out of 13 passing test
response down below I can save the user test suite and is rerunning and down below.
Everything is passing which is great.
Now there's just one more test case I want to take a quick moment to modify down here we have it you
should delete account for user.
Once again it's gonna be your job to make some changes to this test case.
Your goal is to validate that that user is actually removed.
So you're gonna try to fetch the test user from the database and this time you're going to assert that
you do indeed get null back.
You should not be able to find the user because they should have been deleted and you can use that same
assertion we explored earlier in this video to check if something was null.
That was up above in the sign up test and finally you're gonna go ahead and test your work.
So take some time to add those changes to the test case below when you're done come back and click play
all right.
How'd that go.
Let's go ahead and kick things off once again by just getting the response.
Actually for this one we don't need the response so we'll leave that off right here.
We'll start by fetching the user const user equals.
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
created because that's the one we had logged in as when we deleted the user profile and right here oh
we're going to do is assert that user is now no we should not have found a match.
So I'm going to expect that user equals using to be.
No no.
And right here we're all done.
So now we can go ahead and remove those challenge comments save the file for the last time in this video
and right here we should still see those 13 passing tests and that is exactly what we're getting.
So making these super test request is a great place to get started but depending on the test case you
can take it to the next level by looking at the response or looking in the database to make sure things
have changed as you expected.
Now that we have some more advanced assertion techniques in our tool box we're going to continue on
to the next lesson.