Our test suite is up and running.
So let's create a test file to make sure that the new root handler is working as expected inside of
my roots directory.
I'll make a new folder of underscore underscore past underscore underscore and then inside that directory
I'll make a new file of new test.
Yes.
So we're gonna write out some number of tests inside this file to make sure that the new root handler
is working as expected.
I'm gonna go backwards to the new root handler really quickly you might recall from the ticket service
we wrote out a decent number of tests to make sure that some different root handlers enforced authentication.
We also wrote out some test to make sure that users were providing some valid body information or parameters
with the request as well.
Weirdly took a look at how to write those tests so we're not going to focus on writing those tests for
the order service.
If you want to add those tests in and it definitely is worth adding them in.
Feel free to do so on your own.
You can write out some test to make sure that a user is authenticated and if they're not we should respond
with an error and we should make sure that we have a test that checks to make sure that the body the
request has a valid ticket idea as well.
So totally up to you if you want to write those.
We're not gonna worry about them going forward because we really took a look at it in the past.
Instead we're going to really focus on the business logic of our different handlers.
So we're going to make sure that we handle the case in which a user tries to reserve a ticket that does
not exist.
Make sure we handle the case in which a user tries to reserve a ticket that has already been reserved
and then finally handle the success case as well.
When a user actually successfully reserves a ticket.
So in total we're going to focus on writing just three tests around this handler.
So let's get to it back inside of the new test file.
We're gonna write out the three statements right away so we'll say how about it returns an error if
the user tries to reserve.
Actually Let's shorten this thing about returns an error.
If the ticket does not exist let's be a little bit more direct.
Rather than writing out a super long description then how about returns an error.
If the ticket is already reserved
and then finally it reserves a ticket.
So this will be our success case in which everything goes as expected now in all the tests we had written
previously.
We essentially could just write out some implementation inside of each of these different get statements
and that was it.
But now that we're working on a slightly more complicated service where we're essentially operating
over multiple different types of records we're going to see that in some cases we've got to do a decent
amount of setup before any test runs.
So for example with our second and third cases right here we're going to need to make sure that there
is a valid ticket inside the database so we can actually find.
So before we write out any test implementation or actually any logic to make the request itself we have
to manually save a ticket into the database.
So just keep that in mind.
OK so let's take care of this first statement first.
Let's add in a couple of import statements at the very top to make the request so we'll get to request
from Super Test and app from up to directories at
so then for the very first one right here.
Pretty much just make the request make sure we get a forum for it back.
Do keep in mind as well that even though we are not going to directly test and make sure that we've
got this body validation going on this body validation is still going to be executed.
So in other words we do have to make sure that we provide some kind of valid I.D. for the ticket I.D.
in the body the request when I say valid I.D. I mean a valid Mongo D.B. object I.D. So we do have to
import Mongoose at the top as well so we can generate randomly a valid object I.D. at the very top I
will get Mongoose from fungus then inside this first test right here.
Let's randomly generate an I.D. will then make a request attempting to create a new order and we're
going to simply expected to return a forum for status code.
Don't say ticket is mongers types object ideas.
That's how we create a new random idea.
We've seen that once before and we'll go ahead and make our request.
We will await request to app.
I'm going to do a post request to API orders and then remember we are requiring authentication.
So we have to set our cookie in the same way we had previously.
So to do so we had copied over that implementation from our test setup file so we want to call sign
in off the global object and we're going to use that to set the cookie header on our request.
So we'll say dot set cookie global dot sign it
will then send along in the body the request the ticket idea that we just generated in the step previously.
So I'll put in a ticket.
Ticket idea.
And naturally we can condense that down to just ticket ideas and probably condense it down to one line
as well.
And finally we will expect to get back up for a for.
So that should be it for the very first test.
Let's say this look back over your terminal and see how we're doing.
It looks like that test is passing just to make sure that it actually is passing correctly.
I'm going to go back over to the new test handler itself.
I'm gonna find where we are throwing a not found error.
I'm going to copy the bad requester and put it right above the not found error.
So now we're going to get back a status code for a one as opposed to a four a four or submit a four
hundred.
That's what our battery cluster is going to throw.
So this is going to of course our test to fail just to make sure that it's failing in the correct way.
I'll save that put back over.
All right.
Definitely getting the correct thing here.
So we got 400 instead of the four or four that was expected.
Which means our test is probably working as expected.
Well that's our first test.
Quick pause right here and I'll take care of the next two in just a moment.