So now we have a means of storing things in the session for our test, and that's really helpful.
So what I want to do right now is just check our test coverage, which is going to be terrible because
we've disabled most of our tests.
But let's have a look at it and see what is covered and what isn't.
And I'll do that by running my coverage script that I wrote some time ago, which saves me a little
bit of typing.
So as you can see, there's a lot of stuff not covered here, a lot of red in this file.
But don't worry, we'll get this mostly green or entirely green by the time we're done.
But what I want to look at right now is this one.
It's our reservation function.
This is the one we've been testing for the last lecture or so.
And the first thing that's not covered is this Helper's server error.
When we try to pull the model's reservation out of the session, if we can't get it, it fires well
at a server error, which is not really helpful.
We probably should make that a little more useful whenever possible.
I like to avoid just throwing an error of 500 at people and instead give them some meaningful feedback
as to what's gone wrong.
So what I can do is change this and change this, change both of these functions such that if it fails,
it doesn't actually just take you to an error screen.
It takes you somewhere else, which is still part of the website, but gives you some meaningful, meaningful
feedback.
So I'll go back here, open up handlers and find the reservation function.
And I'm going to change this part.
I'm going to delete this error and instead I'm going to put something a little more useful.
So I'll put something in the session.
Emden session not put my app.
Try that again.
Emerg app dot session dot put and I will put in the context arg context.
I will put an error message, which we called error, and I'll just put in the error message can't.
Get reservation from session, which, you know, might that might not be that meaningful to a user,
but this is just an exercise.
You can put whatever error message you want in there.
So I do that and then I will redirect them.
I'll take them back to redirect.
I'll take them to I have to put in my response writer and my request.
I'll just take them to the home page and I'll put it in an error message, a status message here that
says temporary redirect, HDP status, temporary redirect and then return because I don't want anything
else to work after this.
Now, I'll copy the same code and I'll replace this one as well.
And in that, I will change the error message to.
What am I going to call it, can't find room, can't find room?
OK, so now when this test is run and I test it, what I want to test, what I want to do next is run
another version of this test against the same handler and test the situation where there is no reservation
variable in the session.
So how am I going to do that?
Well, I'll go back to my handlers test and I'll go to the very bottom of this.
And what I want to do here is a test case where reservation is not in session.
So I have to reset everything.
And that's really what I'm going to do is reset my request and I can do that just by reinitialize in
that request variable with with an HTTP new request.
So request and an error.
And this time I use the equals sign because I already declared this variable up here.
I'm just reinitialize it and it will just be HGP dot new request.
And again it's a get request, same you URL make reservation and an empty bottle.
So now I've reinitialize that, but I still need to get the context with the session header so I can
just say is equal to get with my request.
And the reason I'm doing that is if I don't do that, I'm not going to be able to even test the situation
where I can't find the value in the session because there is no session.
So this gives me a context that I can then put back in the request, just like I did above.
Request is equal to request with context and pass it the context I just created.
So now I have a session, but that session doesn't have the reservation variable in it because I'm not
going to add it.
So once I've done that, I just create a new response recorder by initializing my our variable with
HDB test, new recorder and then I call my handler handler don't serve HDP with my response recorder
and my request and now I can just copy this, paste it down here, change this to status temporary redirect
because that's what I'm expecting to find in this situation.
Replace it down there and let's try running the test.
So I will go back here, close this just so we can do our coverage in a minute, run our test, make
sure it works.
So I'll clear the screen and say go test.
It should pass.
It does.
Now let's check our coverage.
And when I do that, hopefully that first case will be taken care of because now I've tested a situation
where there is something in the model's reservation, there's a reservation variable in the session,
and I've tested a case where there is not.
And that worked well.
So the only thing left for this function appears to be getting a room by ID.
So I try to get the Rambhai ID.
Now, if we look at in our test database repo, which is under repository DB Repo Test repo, I'm looking
for get Rambhai id find get room there is right there right now.
This just returns an empty room.
So how can I change this function such that I can either a return.
Yes I found a room or B return an error while I'm having, I have this parameter ID that I'm not using.
So let's try this.
If ID is greater then to then do something else instead of returning a model's room, return a model's
room, but an error too.
So I'm going to move this declaration above my IF statement so I don't have to create a second variable
just for this case.
I will say return room and return an error and I have to make that error by hand.
So I'll just say errors donu some error.
Now if I pass it and ID greater than two, it will give me an error.
But if I pass it a one or two it'll return no error.
And that's all I need to do is to simulate the case where you're trying to get a non-existent room.
So let's go back to our handlers test and test with a non-existent room.
Once again, I'm going to want to do all of this stuff.
So I will copy that and paste it here and I'll put a comment in test with non existent room, OK?
And this time I want to put my sessional variable reservation back in there so I can get past that first
case.
So I already have that declared and filled with the necessary information.
So I'll just put it here right after my response recorder.
I'll put my sessional variable reservation in the room.
And now I want to test for a case when there is a non-existent room.
So how am I going to do that?
Well, we need to specify a little one little change in our reservation model.
I want to make sure that it has a remedy of greater than two.
And I can do that just by overriding the value in there right now, by saying reservation room ID is
equal to 100 and that's definitely greater than two.
Room ID there.
So the reason I'm doing that, let's go look at this handler that I'm calling, which is called reservations,
all open up the reservation in this situation at line 70.
In my code, I'm saying I've got the room from the session now get the room by I.D. and I'm checking
reservation room ID.
And I want that test to fail because I want to test the situation where you're trying to get a nonexistent
room.
So I'm populating the member room ID of that model reservation with a value greater than two.
So this should work.
Let's try that.
Let's first of all, close this coverage in our browser, because we'll check that again in a moment.
Clear this screen and go test.
And it passed.
Let's check our coverage and that function reservation should be entirely green now.
And it is very good, so there we have managed to test the situations, enough situations are enough
cases where every possibility is covered for that given handler reservation.
And we can use exactly the same logic for every other one of our tests.
But one of the things I noticed right away is that if I look at my tests, my handlers tests.
There's a bunch of these things that I can test without a session, so I'm going to uncommented this
and then delete the things that I don't want to test.
Well, the first thing I don't want to test is this one.
And I probably don't want to test these ones either.
So I'll comment them back, actually.
No, I don't want to, because these all use the session and they also take post variables.
The other thing that I'll notice that I notice right away is that when I'm looking at these tests,
I actually don't need to pass any post data here so I can delete this entirely.
Just get rid of it, because I'm not going to bother testing the handlers in this table, test the ones
that take a post.
So I'm going to get rid of all of those data's.
And I'll handle those with individual tests, just like I did for the reservation handler, so I can
get rid of this and then get rid of the parameters posted, and that simplifies things immensely.
So now let's try running this test again
and we should see more coverage in her handlers.
I got a typo.
Expect the status code.
It has no parameters.
Right.
So I better actually fix the actual handler itself.
I'm just going to only get rid of this entirely and not bother checking to see if it's a post request,
because I'm actually not running post requests in this test anymore.
There.
Let's try that again.
Go test.
That's better, and now let's check our coverage, which should be better than it was a moment ago.
All right, so this is not getting tested new repo, but it will be before we're done.
Post reservation is not being checked.
I expected that, but these ones are, which is good.
Post availability is not getting checked and availability, Jason is not and reservation summary is
not OK.
So there's still some to test, some that we had never written test before before because we just added
them recently.
But we definitely are getting closer than we were.
We actually now have nineteen point seven percent of our statements tested, which is better than it
was a few moments ago.
All right.
So in the next lecture, we'll start doing a few more of these tests.
We've got our our reservation one done.
The next one looks like it might be post search availability.
So we'll add that and a few more in the next couple of lectures.