In this video we have a singular goal that is to create some more interesting test data to work with.
Right now we create a user and set them up in the database that allows us to test things like the log
in a functionality we want to make sure we do something similar with tasks so we can test those other
end points as well.
Now what does that mean for us it means we need to create some new data right inside of here and we're
going to make some modifications to setup database to get those tasks actually created.
The first thing I'm gonna go ahead and do is load in the task model up above.
So right here const a task equals.
I'll go ahead and use require loading in that model dot dot forward slash dot dot.
Then it's as source models a task.
And down below we'll go ahead and create a few different pieces of data.
I'm gonna create a couple of tasks and we'll even go ahead and create a second user.
We could play around with.
Let's get started with that second user.
Right here.
I'm gonna take everything for the first user are two variables down below what I'm gonna do is just
paste them and changing some of the information.
So for the second one I'll have user to I.D. then the object USER 2.
And down below where we reference the I.D. We want to make sure to grab user to I.D. here and when we
create the JWT and then we can just update some of the data.
So as an example I could use Andrew as the name then Andrew at example dot com and I could change the
password as well.
I'll use something like my house 0 9 9.
Then I'll toss in some special characters as well.
So now we have a second to user that we could introduce into the database.
Down below we'll go ahead and do just that.
We take this line.
We duplicate it and we just change which user we're saving we go from user one over to User 2.
So now we have two users in the database allowing us to create a more real world scenario for our test
cases.
Down below we can see that one of our test suites has indeed failed.
You should sign up a new user.
I'm actually already using that email so I'll switch this up to something else.
I'll use Jess as the name and then just add as an example dot com as the email for that test user.
I don't believe I've used this and I haven't.
Down below things are working now with this in place.
We're gonna go ahead and create some tasks for our users and we'll use those when writing our test cases.
Right here I'll go ahead and create a new constant called the task one and we'll set this up as an object.
Now we are going to define our own I.D. so we can make use of that in our test cases.
There's no need to create it as a standalone variable like we did with users.
The only reason we did that is because we needed the value in two different places down below we can
simply create the I.D. right on the object.
So right here that is new Mongoose dot capital T types Dot.
Capital O object capital.
I d now that we have that in place we can go ahead and set up the other task data we need.
I'll go ahead and set up the description.
So right here in the description for our task.
So we have our task model.
We have to provide all of this data the description for this one could be something like a first task
and we could set completed equal to False and then we also have to go ahead and setup owner.
So right here I'm going to set owner equal to the idea of one of my two users up above.
Right here.
I'll just use user 1 I.D..
I could also use user 1 dot underscore I.D..
Both are identical.
So right here we have a task one then down below we'll end up creating a couple of other tasks.
Now this task isn't being saved to the database just yet.
And that's OK down below I'm going to copy.
Task one and I'm going to convert that over to Task 2.
I still want to generate my idea and I'll change the description to something like second task.
And for this one I'll set it to be true in terms of its completed value and I'll leave this one for
user 1.
Now we'll create just one more by duplicating this object a second time down below.
This is gonna be task 3 we'll leave the I.D. I'll change the description to third task and I can leave
the completed value at True or false.
Either one works and we'll set owner equal to user to dot I.D..
So now we have a couple of users and each have tasks giving us some real world data to use down below
all we need to do is update setup database to actually delete the existing tasks and add these three
into the mix.
So down below I will use a wait with task and write here using delete many exactly like I did on the
line above for users.
Then down below where we create the users we will create all 3 tasks.
I'll define a new one.
Task 1 calling these save function.
I can then take this line and paste it 2 times down below.
So we save Task 1 then Task 2 woops.
I had some extra characters in there and then after Task 2 that would be task 3.
Excellent.
Now with this in place there's no need to make any changes to our test suites.
They are automatically going to use all of the new changes we've made.
Now if we rerun things everything should be passing end it it's right here.
We still have eleven passing test cases now that we have this more interesting data though we can take
advantage of it over inside of our task test suite and that's exactly what we're going to do down below.
This is going to be a challenge for you to knock out on your own right here are the challenged comments.
You're going to write a single test case for get tasks you're going to ensure that when you fetch the
tasks for a given user you only get those user's tasks back.
So right here you're going to first create the test case and use request to make a request for all tasks
for user 1.
Then you're going to assert the correct status code and you're also going to check the length of the
response array is 2 so over in DB dot J S How many tasks does a user want to have.
They have to.
That's exactly what I should be getting back if I'm getting back less.
We have a problem.
If I'm getting back more we also have a problem because this should not be returned as a task owned
by user 1.
It's owned by user 2.
Now once you have that assertion in place you're going to test your work by running the test case and
you should go from eleven passing tests to twelve.
So right here take some time to knock that one out test your work and when you're done come back and
click play
how that go.
Let's kick things off by calling the test function and providing a name should fetch user tasks.
We'll set up our function as an asynchronous function and down below we'll kick things off by making
that request so const response will store the response.
I will await the call to request a passing in app.
Then we'll set up dot get this is a get to request to the following end point forward slash tasks.
Now if we were testing one of our options we could provide those here such as only getting tasks back
that are completed or incomplete or getting them back in a specific order or a specific page.
Right here though we just wanted everything and then down below we'll make sure to set up authentication
so dot set setting up authorization providing the correct value that is bearer followed by the token
user one dot tokens grabbing the first one and accessing that token property.
Then we're going to use send to send it off.
Now in this case there's no need to provide a request body.
So I'm not going to provide any arguments right here.
And finally I'll add the call to expect on to assert the status code is a two hundred.
Now we want to make sure that the length of that response is too.
So if you forget exactly what your data comes back as it's okay.
If you need to look into the router file for example I could go into the task router I could find that
specific end point and I could see what sort of structure I'm getting back right here.
I can see I'm getting back an array that means over inside of my test is suite.
I can set up the correct assertion.
What I'm going to do is expect something about response dot body.
I'm going to expect its length I'll access the length the property to equal the following number of
the number two.
If it's too great if it's not we have a problem.
Now we can remove our challenge comments down below and actually test things out.
We should have those 12 a passing test cases right here.
That is exactly what we end up getting.
So now we have more interesting test data allowing us to write test cases like this where we fetch data
for a specific user and make sure that's all we get back.
Now let's work through a second challenge of a similar nature down below.
You're going to test the security of the delete task operation so you're going to attempt to have the
second user delete the first task.
Now the second user is not the owner of the first task.
So we would expect that this operation would fail.
Now in order to get this done you will need to export some stuff from DB.
Dr. J asked.
That is currently not exported all of the new stuff we created.
Once you have that loaded into this file you're actually going to send off the request trying to delete
that first task as the second user.
Then you're going to assert you get the correct failure status code and you'll assert that that first
task is still in the database it should not have been deleted.
Finally you'll test your work by saving the test suite and looking for 13 passing test cases down below.
So take some time to knock that one out.
You can create the new test case right here when you're done come back and click play.
All right.
How'd that go.
I'm going to kick things off by exporting the new items we created over in DB dot J S now we could export
just what we need for example something like task one so we can get its I.D..
But I'll go ahead and export all three tasks as well as the data for that second user.
That means down below.
We're going to add some more stuff right on here.
We'll have user to I.D. then we'll have user to we'll have a task.
One task two and finally task three making sure the other file can access anything that it might need.
Now we can go ahead and save this one and load in just what we actually need over here.
So we want the second user to delete the first task which means I need both of those pieces of data
up above when we're actually.
Excuse me when we're dis structuring an object we typically want to keep it on one line.
If you're just grabbing a couple of things but if you find yourself grabbing quite a few things you
can go ahead and break that onto multiple lines like this.
A very common thing to do and with this in place we can now easily grab other things we would like as
well.
For example I can grab user to I.D. I can go ahead and grab user 2 and I'll grab my tasks as well.
Even if we're not using them right now.
Task 1 task 2 and Task 3.
And with this in place we're now ready to actually create that test case down below.
Let's do just that by calling test a third time in this file right here.
Test should not delete other users at tasks.
You might have picked a different name.
That's perfectly fine.
I'll set this up as an async function and then we'll go ahead and actually make the request.
So as that second user we want to delete the very first task I'm going to kick things off by creating
my response variable and awaiting my call to request I'll pass in the app.
Then we'll go ahead and set up this specific type of HDD requests we're making.
This is using delete with the following path.
Now the path is going to include the I.D. of that first task so I could use a regular string and use
concatenation with the plus operator or I could use a template string either approach is perfectly fine.
That is forward slash tasks forward slash the task I.D. right here.
That for me will be the following that is task one dot underscore I.D. then down below we want to make
sure we're authenticated as that second user.
So I'll be setting up the authorization header with the value bearer followed by the token for that
second user right here.
That would be user to dot tokens grabbing the first one by its index and then grabbing the individual
Jason web token and then we'll go ahead and send this one off to the server.
Now for this case there's no need to send any data so we can move right along to our expected call and
if there is no task found with that I.D. owned by that user we know we get a 4 0 4 back.
So that takes care of everything in steps 1 and 2.
Next up I want to make sure that task is still in the database down below what I'm gonna do is try to
fetch it.
Const task equals.
I'll use a task and find by I.D. to fetch it.
I have task one dot underscore I.D..
Now I am going to go ahead and use a wait with that and then we're just gonna make an assertion that
we actually got a task back.
So I will expect task not to be null.
Perfect.
Now with this in place we're all done.
We are setting up everything including our assertions.
I can remove the challenge comments as all there is left to do is to test our work.
Right here we can see the first test suite has passed and then the second we have 13 passing test cases.
Now at this point we have a pretty good test suite in place in the next lesson.
We're going to wrap up this section on testing by going over some other test cases you could now right
based off of what you now know.
I'm excited to get to that so we'll see you in the next 1.