Our tests are all complete.
So let's go ahead and build out the actual show root handler inside my roots directory.
I'll make a new file of show dot yes we're then going to add in everything required inside of here to
actually build out our root handler.
So I'm going to import Express and the request type and the response type from express without a doubt.
I'm going to need to be able to access my ticket collection inside the database.
So I'm also gonna get my ticket model from up one directory models.
Ticket I'll then build up my router with Express dot router I'll then set up the handler itself though
router dockets we want to watch for get requests to API tickets and then the I.D. of the ticket we're
looking for we're going to be making a request to our database from inside this thing.
So it's definitely gonna be an async route handler I'll then add in my rec as request and rez as response.
And then finally just because we know we have to do it let's export this thing right away and wired
up to our app at the very bottom up it in an export router as show ticket router
I'll then go back over to my apt to yes file
I'll add an import statement for that router
from roots show and then again we'll wire that up to our app.
So app dot use show ticket router.
All right.
Gonna save this now after we save all this stuff our tests are going to rerun and you're probably gonna
see your tests hanging.
The reason for that is that we've now got a root handler to receive these incoming requests to the show
route but we're not actually responding in any way.
Eventually the test is going to time out.
I believe the default just is about 20 or 30 seconds.
So actually if we flip back over after some amount of time it will tell us it looks like my default
is actually five seconds in this case Doctor five seconds it naturally times out and both tests fail
let's put together some implementation.
We're going to first try to focus on getting this one right here to pass so on to make sure that if
we cannot find the ticket let's return a 4 or 4 right away inside the root handler.
All we have to do is use the ticket model to look into our collection and find the idea that was mentioned
in that your URL will say counts ticket is a weight ticket dot find by I.D. And we're going to execute
this query with the REC ramps that ad I.D. so wrecked out perhaps I.D. That is the idea that we captured
out of the URL find my I.D. is a query helper built directly into our model as you'd guess it's just
going to try to find a particular record coming out of this query.
We're going to get either our ticket documents or if nothing was found it will instead be equal to no.
So now we can take a look at tickets and if it is equal to nil or essentially if it's not defined then
we definitely want to return a status code of 4 0 4 to the user.
So let's handle that first.
Well say if not ticket then we need to return the status code.
So naturally we could do that return resorts and status blah blah all that stuff.
But remember we've got that fancy fancy fancy airy handling system already put together.
If we think back to our common module inside of our ears directory we had put together that custom air
of not found air.
Nothing was really built specifically to handle the case array and right now the case in which we make
a request and try to find something that just does not exist so if we do not find a ticket what we should
really be doing is throwing a not found air to do so.
Let's import not found air from our common module and inside of your throw new not found
then if the ticket is found let's send it back in response.
So after the if statement we can do a resort send ticket whenever we leave off a status code it will
default to two hundred and so that two hundred will be successfully caught by that expectation right
there all right.
Now I'm going to save this file.
We're going to check our test output.
I want you to know that we're going to see an error.
Something's going to be failing erroneously.
And the reason for this is well we're gonna take a look at it is an error they wanted you to see on
your own just to see that even though yeah we could write tests sometimes they don't quite work as expected
and sometimes they actually help us catch them.
Issues that we would have not really found if you were just testing this inside the browser.
Let's save this flip back over tests are running and it looks like our test to successfully create that
ticket and then fetch it worked that one passed.
So the good case this longer one right here that thing passed but this one failed.
The one we were checking to make sure we got a four a four.
So we got a message here.
We expected to get a forum for status but instead we got back a four hundred.
That is definitely unexpected.
So we're going to have to do a little bit of troubleshooting a little bit of debugging to figure out
why this is happening.