- [Instructor] An often held, but mistaken belief,
is that 100% test coverage means that software is perfect.
Should you try for 100% test coverage?
Yes, but with a huge caveat.
100% test coverage does not mean
that your application is bug-free,
especially if you designed your tests to conform
to the buggy application.
100% test coverage does not mean that you wrote good tests.
It just means that your tests didn't fail.
100% test coverage could mean
that your tests were not properly isolated,
so unexpected behavior could still occur.
Practically, a user of the system
can't use 100% test coverage
because it does not deliver new functionality.
Finally, 100% test coverage is not a substitute
for peer code review.
Okay, without out of the way,
what does 100% test coverage look like?
Rather than dragging you through writing
a number of digital tests,
I've gone ahead and done the work already.
If you really want to learn, try to get to 100% yourself.
Either way a solution is available in the exercise files.
Switch over to VSCode, navigate up to file,
and then add folder to workspace.
Navigate to wherever you have your exercise files,
go to solutions, and then the file folder 05_06, click add.
Within the explorer, scroll down to the bottom.
Right-click on the app.test.js and go to copy.
Above, right-click on the nadia folder
that you've been working on and choose paste.
Go back down to the bottom of the explorer, open routes,
and control and click both of the files.
Right-click and go to copy.
Above, right-click on the routes folder, and go to paste.
Close any open files.
We're all done with a source folder,
so we can right-click on it,
and go to remove folder from workspace.
Click on nadia to focus it,
and then open up the terminal.
Maximize the window.
And are you ready?
Type npm test.
There it is, the elusive 100%.
Wasn't that easy?
Too easy?
There might be a catch.
In the tree view, open up views,
and select reservationform.pug.
If you scroll down, you can see that the party size,
the options go from 1 to 8.
Now in the explorer, open routes,
and select reservations.test.js.
Navigate to the valid reservation request post.
Change the party size to 8 and save the file.
From the terminal, run the test again, npm test.
Well, that's not right.
Let's see what's happening.
Back in VSCode, let's check the schema.
Open up lib/schema/reservation.js.
Navigate down to validate and look at the party size.
Ah, that's your problem.
The max size is 7.
Change it to 8 and save the file.
From the terminal, run the test one last time, npm test.
Phew, back to 100%.
The moral of the story.
100% test coverage does not mean
that the application is bug-free.
100% test coverage is a good goal, honestly.
With that said, it's not the only goal you should have.
Test well, test effectively, and find a balance
between delivering functionality and testing.
We've got reporting on test coverage now.
So how can we automate these reports?