I'm back inside of my test where we're going to try and check to make sure that a ticket was actually
saved or our database.
There's definitely a wide variety of ways we can do this.
I think that we're gonna take a very simple simplistic approach.
What I would like to do is first do a check and see how many records are inside of our ticket collection
will then make the request and then after that we'll once again check to see how many records are in
there.
And we should see that there should be one additional record after making the request.
So let's write out the code for this.
I think you'll understand where we're going with it really really quickly to get started.
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
going to import ticket from up up models.
Ticket
back down at the bottom and then going to look into my tickets collection and take a look at all the
different tickets that exist inside there.
So I'll say let tickets is a wait.
Ticket find with empty object.
So this query is going to get all the different tickets that exist inside of that collection every last
one.
Now when I say every last one that's kind of a little misleading statement.
You might recall that back inside of our test setup file after every single test that we run or I should
say before every single one we take a look at all of our different collections inside of Mongo Mongo
DB.
And we delete all the data inside of every single one of them.
So when this test first runs there should be zero tickets let's write out an expectation around that
right away to just confirm there are zero tickets inside the database right now it's open and expect
tickets not length to equal zero.
By the way notice I'm using the like.
You were right here.
That's because we're going to reassign that variable right after we make the request.
So now we make the request you might notice that we're missing a little step inside of here.
We never actually added any check or any authentication step.
So very similar to what we did back up here.
Let's make sure that we set that cookie so after calling post I'll do a set cookie global sign in
now after making the request.
Let's take a look at all of our tickets inside that collection once again.
And we're going to expect there to now be exactly one ticket inside there don't say tickets.
Again that's why we use the left keyword right here so we can redefine this variable is a wait.
Take a dot find and we should now be able to expect tickets dot length to equal one if we wanted to
we can also take a look at the record those actually created and write out an assertion about say its
title or its price.
So for example we could do something like tickets at zero dot price to equal 20.
We could do the same thing for the title as well.
Totally up to you if you want to write in an assertion around the title I would recommend extracting
the ticket or that title right there to a separate variable.
That's something like Idol is blah blah blah then use that as the title and then for the actual assertion
expect tickets zero title to equal title.
Well that is it for our test.
So let's save this.
We're going to go back over to our terminal and just make sure the test is failing.
Yep definitely is.
Now let's go work on the actual implementation.
I'm going to go and find my new root handler at the very top.
I'm going to import the model that we just created so we can actually save some data so we'll go up
one directory models.
Ticket
then down inside of this thing you can remove the red dots and status.
We're going to first tried to pull off the title and the price from the body of the incoming request.
So to pull off that data title in price from wrecked out body will then build up our ticket.
That's gonna be ticket duck billed.
Remember that's how we are creating records here because typescript can jump in and make sure that we're
providing the correct structure of data that we'll put in our title we'll put in the price.
And remember there is a third property required we have to put in the user I.D. of the person who is
creating this ticket.
So we know who actually owns it.
OK.
So we'll say that the I.D. is going to come from rec print user I.D. number.
We have access to current user on that request object because we had previously executed our current
user middleware back inside of app.
Yes that thing right there.
That's what sets the recurrent user property.
We are getting complained out by typescript right now typescript is saying hey this I.D. thing might
not actually be defined.
Remember whenever we set current user we are possibly setting current user if the user is not authenticated
then the current user Middleware is not going to set current user to anything.
And that will be undefined right now typescript a saying hey you can't look up the property here.
You have to make sure that the current user actually exists.
Well we don't really have to do that.
You might recall that or require auth middleware already does that for us.
If I go back to the definition of the require middleware instead of our common module right here we
are inside this middleware doing a check to make sure that current user is defined and if it's not we
then throw this air and we never continue on to the next middleware or possibly the next request handler
in this case so in other words right now we're never going to end up in this statement right here.
If current user is undefined touch script just doesn't understand that because it is not looking into
the require auth function and understanding that we're going to return early out of this entire chain
if current user isn't defined.
So I feel pretty comfortable adding in a exclamation to this thing and telling typescript Hey don't
sweat it print user is defined.
We've got this thing defined.
Now you notice that even after that I'm still getting in air here I put in ideas right here.
That is my mistake.
It should be user I.D. That's better.
So there's our ticket we've built it up.
After that we need to actually save it.
I'll do in a wait to get dot safe if I want to use the awake.
You were inside of here as usual.
Well Mark the enclosing function with async after saving that record we can now do a rez status
to a 1 and we will send back the ticket that we just created and that should be at so let's save this
will go back over to our terminal and all of our tests are passing fantastic Well this is pretty good.
Now at this point you might be thinking Steven writing his tests such a pain such a pain so much extra
stuff to go through.
Well here's the good thing about it.
We spent just a little bit of extra time really not that much writing out these tests and even as we
going through that we had do a lot of extra setup stuff but we've now got a root handler and we are
really sure that it works the way we expect without ever having to actually run our code inside the
browser or at postmen.
So this really is a great advantage during development.
We do not have to be manually testing everything over and over and over again.
And we've now got this great record right here of how this request handler should behave so we can start
to make changes to it now.
And if we start to break it in some particular way.
Well we've got something to yell at us and tell us hey you're doing something wrong.
Go fix it up.
So if you don't like writing tests out I apologize for that but I really feel very strongly that this
is the right thing to do when we are developing micros services because we don't have to go to the process
of wiring this take it up to everything else inside our application where the react app or whatever
else just to make sure that's working as expected.
All right.
So now that we're all done with creating a ticket we're going to take a pause right here and in the
next video we're gonna move on to our next request handler.