Our index right handlers put together.
So let's write out a quick test or two.
Just make sure that the thing is working as expected and starting my test directory.
I'll make a new file of index test.
Yes at the very top.
I'm going to add in a couple of different imports or some things that we're definitely going to need
inside of here.
So first we probably need request from Super Test.
We probably need our Express application from up to directories app and then we are probably going to
have to create some different orders and tickets.
So I'm going to import the order model and the ticket model as well.
I'll get order first from up to directories models order and same thing for ticket
I'll then write out a single test case here.
Really just gonna do one single test where we're going to make sure that we can find a list of orders
successfully.
It's all put together and it's statement and I'll give it a description something like it fetches orders
or a particular user
testing out this row handler is going to be a little bit more complicated than it might seem at first
glance.
Only reason for that is that we write on a test we probably want to make sure that we only find orders
that belong to the user who is making the request.
In addition we're going to make sure that when we ever we get a response we also fetch and supply the
associated ticket as well.
So let me show you how we're gonna write out this test.
I'm gonna write a couple of comments just to guide us as we go through it.
So inside of here I'm going to first rate three tickets.
They're gonna make three separate tickets say them to the database.
We're going to create these tickets using the ticket model right here directly because remember we do
not have any kind of request handler or anything like that inside of our app right now that we can use
to manually create a ticket.
The only way we can create a ticket is through the ticket model.
After that we're then going to create one order as user number one and then create two orders as user
number two.
So for these three tickets we're going to create three separate orders.
One ticket is going to be reserved by user number one and two tickets will be reserved by user number
two we're then going to make a request and try to fetch all the different orders or specifically at
user number two I'm going to write out a quick comment for that I'll say make requests to get orders
for user number two and then when we get that list of orders we're going to write out an expectation
to make sure that we got the two orders we had created right there but not the first order that we had
created for user number one because that's really the key to this request handler.
We want to make sure that we only fetch orders for the user who is making the request to the actual
expectation down here is to make sure we only got the orders for user number two and the only reason
I'm writing on all these comments is that this test is going to be pretty large in nature.
There's a lot of code here we could definitely try to figure out some way to split this into multiple
separate tests but I think just writing it out all inside of one test is gonna be just fine okay.
So with all that in mind let's get to it first.
We're gonna do is great three tickets using our ticket model.
We could write out the ticket dot build method right here three times instead I'm going to create a
little helper function just to make it a little bit easier and concise to create these three tickets.
So right above the it walk I'll write out build ticket
and then inside of here I'm going to create a ticket
with ticket dock built I'll give it a title of concert and a price of twenty or then do and a weight
ticket that save and then return the ticket itself.
I'll make sure that I marked the enclosing function as a sync and now down inside of my actual test
I can call that Bill ticket function three times so I'll do ticket 1 is a weight billed ticket and then
copy paste that down twice and I'll change the names to ticket to and ticket three.
All right.
Not that bad.
So there's our three tickets next up we're going to try to create art.
Three different orders one as User 1 and 2 as User 2.
We're definitely going to want to be able to make follow up requests as user number two.
And that means that we're going to end up having to store the cookie that we get back from calling that
global dot sign and function that we can make a follow up request as user number two later on the right
above that first comment.
I'll say User 1 is global dot sign and we don't actually have to make a false request as User 1.
Nonetheless going to store this in a variable just so we can really understand where we are using each
these different users then USER 2 will also be global signing.
So we can very easily make requests with as either User 1 or user number 2 OK.
So now we're going to create an order as user number one we're going to make sure that we do this making
a request through our Express application as opposed to creating an order directly with the User model.
The reason for that is that remember it's kind of hard for us to extract the ideas of a particular user
directly from this cookie that we just created.
So it's going to be a lot easier to kind of correlate the orders right here that are being created on
with the follow up request.
If we just use a cookie directly as opposed to creating the different orders using the order model.
OK.
So first we'll do it in a wait request to app.
We're gonna do a post to API orders and we'll set our cookie to User 1 and we're gonna send along with
this a ticket I.D. of ticket one dot I.T. and then we're going to expect to get a two a one out of that.
So we should be able to successfully reserve ticket 1 for user 1.
All right.
So that's it for user number 1.
I'm not can repeat this process twice for user number two.
I'm going to just copy that entire block right there and then paste it down here twice then for user
choose first request I'll make sure that I update the cookie to user to end user TOS first request is
going to try to reserve ticket
then on the second one will update the cookie to User 2 and in this one we're going to try to reserve
ticket 3 like so all right.
Now in theory our entire entire data model is complete.
We should have everything properly associated and saved inside of our database.
So now we can make a request to get all the orders for user number 2 and then write out some expectation
about the data that we get back in response.
So put inside of your accounts response is a wait request to app.
We want to make a request to the index or handler.
We just put together.
So that will be a get request to API slash orders.
We'll do a get to API orders and we really want to make sure that we make this request as specifically
user number 2.
So we'll set our cookie to user to
we're going to expect to get back at two hundred and then we'll take a look at the response and make
sure it's got the appropriate information inside of it.
So right now.
How about we just do a console log of response dot body and we'll figure out how to best write out some
expectations.
I'm going to say this.
Let's flip back over to our terminal and see how we're doing.
All right.
So let's good so far I don't see any errors around the index test and I do see a console log right here
that definitely has only 2 orders inside of it and inside of each of these orders I see the embedded
ticket as well.
Let's say this is off to a good start.
Let's now go back over and let's start to write out an expectation or two so I'm going to write out
expect response dot body to have length
to make sure that we only got back two tickets.
In addition we should probably make sure that the minute we got back to orders we should really make
sure the two orders we got were the correct orders as well.
So I going to try to save a reference to the response we get back when we create these two orders.
So we know the I.D. of those two orders and we can write out some kind of comparison or expectation
and make sure that we got the two correct ones so I can write out response 1 and response two.
Now calling these responses response one in response to.
Yeah.
It would technically work but that's kind of confusing to see response one response to and then another
variable down here called response.
So instead we're going to d structure just the data we care about these responses and as we d structure
it we're also going to rename the variable as well.
Let me show you what I mean by the first request right here for no user number two I'm going to delete
response one and the only thing we care about out of here is the body property right because that's
the actual order that we're being sent back.
Same thing on the second one as well but we cannot just have body in both cases.
So we need to somehow restructure these things and simultaneously re name them at the same time to do
so we're gonna put in body then a colon and then order one and order two like some.
So this is two steps and one we are de structuring out the body property off the response we get back
to the request and we are simultaneously renaming that body property to order one.
So now we've got a variable of order one that we can access in the rest of this test and it's going
to be equal to the response so we got back the body.
The response we got back from this first request right here.
So order one really should be well an order object and we can confirm that very easily if we just do
a console log down here of order 1 I'm going to save the file pull it back over and I'll take a look
at what gets console logged so Yep there we are right there that is definitely my order.
So now we can delete that console log and write out some expectations to make sure that we got the correct
orders back instead of response I'll do an expect response dot body at zero 1 Take a look at the idea
and I want make sure that it's equal to order ones i.e.
I'll then copy paste that on this next one I'll update order body to 1 and I want to make sure that
is equal to order choose IP you're going to say that look back over and there we go everything's passing.
All right a little bit of a longer test here but it definitely works optionally we can also take a look
at the ticket that was embedded on both these as well.
So if we wanted to do that we could write out an expect for response body 0 ticket i.e. it'll make sure
that equals
ticket to his idea and then the next will be ticket three ideas is specifically going to be ticket to
because order 1 had a reference to ticket to so we put inside of your ticket to daddy and then I'll
do another copy paste their updated to body at 1 make sure the second ticket inside their as an idea
equal to ticket 3 that idea all right well let's test here so save the file pull back over and we're
looking good as usual you might want to just make this fail just make sure all the tests are actually
working and it's actually reloading this file properly so I'll find one of expect for the status code
change it to a 500 rerun the test and okay.
Definitely looks good so I'll change that back over 200 again I'm just doing that to make sure that
the test suite is actually updating this actually properly running our test all right well that's it
for our index root handler now I apologize for like this video could've been a little bit shorter but
figured might as well get it all done in just one single video let's take a pause right here and we're
gonna take a look at our next root handler in just a moment.