As I just mentioned we're going to write out a really quick test around this show a root handler inside
my test directory.
I'll make a new file of show test.
T.S. then at the top couple of imports here.
As usual we will get requests no brackets on their from super test.
We'll get our Express app from up to directories app and we'll also all in the ticket model so that
we can create a ticket so that we can associate that thing with a new order so we'll get ticket from
up to directories as well models ticket will write out our actual test will say it matches the order
pretty simple inside of here we're going to once again create a ticket will then make a request to build
an order with this ticket and then finally make a request to match the order
when we make the request to build the order with the ticket and then the follow up request to fetch
the order.
We once again need to make sure that we're making those two requests as the same user because if we
make these as different users then chances are trying to fetch that order is going to fail because we're
trying to access a order that's been created by a different user.
So again it's just going to look pretty similar to what we did back inside of our index test file not
a lot more explanation needed.
So let's get this code together first thing create the ticket because we're only creating one ticket
inside of here.
Right now we'll just create the ticket directly in line rather than creating a helper function will
say ticket is ticket dot build with some title and a price then save our ticket after that we'll create
our user with global sign in and when I say create the user I'm really saying we're going to create
a cookie that encodes some particular user inside of it we can then make a request to build that order
with that user and we're going to build the order with that ticket so we'll do it in a weight request
to app we want to do a post request to API orders we definitely want to authenticate ourselves as the
user that we just created and we're gonna send along a ticket I.D. of ticket dot I.D. And then finally
I'll expect that that goes successfully.
So we'll do it in an expect of 2 a 1.
Now when we built up this order it's going to give us back our response and inside of that response
is gonna be the idea of the order that was created.
We need that order I.D. because when we access the showroom handler we have to specify the idea of the
order that we are attempting to fetch.
Don't make sure that we get the response here.
Once again we don't really care about the entire response.
So we could do structure off just the property we care about which is body we don't even care about
having a variable name necessarily body.
We really kind of made you want to rename this thing on the fly once again and say that this is the
order that we are trying to find
now we'll make our follow up request to fetch that order I'll do in await request to app we'll do a
get we're gonna use some string templating here so notice the tactics we'll put in API orders and get
the idea of the order that we are trying to fetch.
And that idea is gonna come out of that order variable right there.
So we'll do some string interpolation order dot I.T. we'll make sure that we set our cookie so that
we are making this request as the same user are going to set it to user.
We will send this request off.
And then finally we will expect to get a two hundred back
and we could definitely tried to get the response that comes back and take a look at the data that we
actually received.
So for that we could do structure off body once again in this case.
I will rename that body variable just to distinguish it from the body up here as batch order and then
we can write out an expectation to make sure that this thing has the same ideas as the order that we
created.
Up here so we could do an expect batch order not I.D. to equal order dot I.D. gets Alex good we're gonna
save this.
Take a look at our terminal and see how we're doing and it looks like we're passing.
As usual I'm gonna change one these expectations to say five hundred just to make sure the file actually
got saved updated by just Yep looks like it did.
So we're good to go okay.
So this right here really tests out the happy path or everything going as expected.
We could also add in one or two tests to make sure that if the order is not found we return it for a
four or probably more importantly if the user tries to fetch an order that doesn't belong to them.
We sent back a for a one of not authorized.
I'm not really gonna sweat the forum for you could definitely write out a test on your own if you want
to test that but I think that it would be kind of nice to make sure that one user is not able to fetch
another user's orders so I can write out a very quick test for that and I'm only going to write out
very quickly because well we can really just copy paste the test we already wrote changed one or two
variables and make it all work as expected.
It's gonna take the entire test we just wrote or copy it and then paste it down right underneath I'll
change the description of this copy paste to it.
Returns an error if one user tries to fetch another user's order.
We could probably write out a better description there but I think that's pretty well descriptive now
in this case.
We're going to still build up a ticket it's still going to create up in order but then when we make
the request to fetch that order we do not want to make this request as the same user.
So rather than putting in the same use right there I'm going to create a new user by calling global
sign in so now we're going to in theory get back a 4 or 1 status code from this.
I don't really care about the body that we get anymore so I'll delete all that stuff and also delete
the expectation at the bottom and I should be able to just change the status code on the expected 2
4 0 1 All right.
Let's say this and see how we're doing
and it passes as usual.
Real quick change here.
So I'll take it over to 500.
Make sure the thing fails
Yep.
Looks good.
Back to 4 0 1.
And we are all set.
Well that's pretty much it for our show.
Root handler pretty effective test for it so we just have one last row handler.
We've got the one that's going to allow us to delete in order or essentially cancel it.
Turns out we're not going to actually delete it out of our database but we will go ahead and cancel
it.
We'll take a look at what we really mean by that in the next video.