So let's check our coverage for the handlers package and see what kind of test coverage we have right
now, and I want to go to my terminal and the command to do that is really easy.
Go test dash cover.
And that will show me that I've got about seventy nine point two percent of the statements covered in
the package handlers, which is a pretty good percentage, but it should be better.
So let's look at the HTML version of that and I'm going to show you, first of all, how to do it from
the command line and secondly, how to do it from the command line without typing a whole bunch of things
and potentially making lots of errors.
So the command to do that is here.
And this is on Linux.
On Linux.
I can do it as one line or on a Mac.
I can do it as one line on windows.
You have to do it as two separate commands, but they're the same commands.
Go test, test, dash cover.
Profile equals coverage out, which will create a file called coverage out.
And then on Mac and Linux, the double ampersand says if this succeeds, then run the next command.
If it doesn't, then stop and the next command is go to cover dash HTML equals the name of the file.
We created coverage out, so I'll press enter to get this coverage and there it goes.
Fires up my web browser will only have one package to look at.
So here it is.
Things that are Ingrey are not tracked and can be ignored.
Things that are in red are not tested and can't be ignored and things that are in green are good because
we have coverage there.
So we'll just scroll down till we see some red.
Here we are post reservation, so a lot of red in this one.
So the first one says if we can't pass the form printing error in return, I can live with that.
OK, that's not a big deal.
But the next one, if the form is not valid, this never gets executed.
And that's when I actually do want to test.
But not right now.
As I said, the last lecture, we'll do that once we have a means of storing information in the database.
So we'll come back to that one.
Let's keep going.
And down here, if we can't marshal the Jason from this, that's not an issue right now.
That doesn't bother me.
I'm going gonna leave that one alone.
Here's one that does bother me.
This is when reservation summary.
Now, hang on a sec.
Do we even test for reservation summary?
Let's go back and look.
So handler's test.
No, we never even called that one.
Well, there's one we have to add, so we'll do that, not right now.
I'll leave that as an exercise for you right now.
But the next time I'm working on this test, I'll add it.
And you know, just two things here.
The first part of this reservation summary did get cold.
It got cold after we did a successful post or make reservation post.
So this worked and it actually gave us an error, which we didn't even know until we looked at our test
coverage.
And the error was cannot get item from session.
So we'll have to go modify our handlers to handle sessions the same way that we did in our surrender
package.
And we could do that then.
And that will take care of this situation as well, because then we would be able to test for it.
All right.
So that was for that one.
Now, as I said a moment ago, I really don't like typing this long, command this one out.
So what I'm going to do, and this will only work on a Mac or Linux is I'm going to go open a new tab
or go open a new terminal window and I'll go to my home folder, which is right here.
And on a Mac, at least a recent version, you're going to have a file called Z Profile, Dot, dot,
Z profile.
If you don't have one, you could just create it.
I have one.
And here's where I put things that I really don't want to retype.
And I do it using the Syntex alias and I'm just going to say an alias for the command coverage that's
going to equal.
And then I'll paste in that long command.
And once I do this, I then have the ability to go back.
I'll create a new terminal window, go to my Google and projects.
You might have to close your terminal window and reopen it to have it reload, but do that if necessary.
And then I'll go into my bookings folder and then I'll go to say handlers, internal handlers and I
can just write coverage and it will do that for me, which is ever so much easier to type.
That's just a little hint to to point you in the right direction.
Now we can also, of course, look at our coverage in our Brender package so I can just type coverage
or type out that long command or those two commands if you're on windows and we'll give you the same
thing.
So what kind of coverage do we have here again?
Eighty point five percent.
And we can scroll through and see what is tested and what is not.
And as you can see in the vast majority of cases, these are the sorts of things that just don't bother
me.
So up here, again, I'm not too worried about that one.
I'm not too worried about that one.
This one I can actually fix.
It says if app use cash, get the template cash from the app config.
So I could fix that one really easily just by coming back into my render package, which is right here.
Look at my render test.
Where was that.
That is testing for render template so I could find test render template and all I'd have to do is come
down here and set app to be app use cash to be false or true and run the test once and that would cover
that.
So you can you can get closer to 100 percent coverage without much difficulty.
Now, as I said before, I don't really sweat the full one hundred percent test coverage.
As long as I'm covering critical code, I'm happy.
I am not a purist in that respect.
There are purists and I'm not criticizing them in any way, shape or form.
But for things like this, for example, log fatal error, we're going to improve our error handling.
I'm not too concerned about this right now.
Little little catches for errors like that don't concern me too much at this point.
Now, as time goes on and the application becomes more sophisticated, we'll be paying more attention
to things like that.
But I want to write the error handling package code before I bother testing this sort of thing.
All right.
That's enough for this time around.