- Knowing about problems within a specific file or component
is a good thing.
But that's only part of the picture
Having an actionable perspective of the entire code base
is a key to success.
In this chapter, we're going to extend what we've learned
so far about testing and detecting suspicious code.
We'll start with a concept of code coverage
and why it's important.
We'll generate a report about the restaurant reservation
applications code coverage using industry standard tools.
Next, we'll broaden our testing techniques
with functional testing,
which will extend the existing the report.
We'll ask the emperor has no close question.
What could possibly go wrong
when you have 100% test coverage on a code base?
Finally, we'll learn about ways to automate
code quality measurement on an ongoing basis.
Code coverage sure sounds important,
but what is it?
Code coverage which is the measure of how much code
is executed in a given operation.
It's typically from a test suite,
but there are some other tools that measure things
like client side code execution.
Code coverage is reported in percentages,
like 76% covered.
A higher percentage means more code was executed.
Code coverage is important for a number of reasons.
A higher percentage of coverage reduces the risk of bugs.
Notice I said reduce, not eliminate.
Like security, there are no absolute guarantees of error
free code.
Code coverage highlights unused or untested code components
which can be helpful for optimization.
It's also an indicator of code quality.
Being able well to report the code coverage indicates
an interest in effort to improve the software.
Finally, code coverage is a requirement in some types
of mission critical industries,
such as avionics and automotive safety.
You're probably not writing no JS code
for these types of applications.
But my point is that code coverage is a recognized way
to raise confidence in code quality.
There are four typically recognized types of code coverage
which I'll define and then demonstrate.
The first are the proportion of executed statements.
Next, are branches.
Then the proportion of called defined functions.
Finally, the proportion of executed lines.
The percentages often we'll be pretty close to each other,
but you can have a hundred percent line execution
but miss out on some branches.
Here's an example of a code coverage report
which we'll be generating ourselves in the very near future.
The columns are pretty straight forward.
It starts with the file of directory.
Then the percentage of statements, branches, functions
and lines.
The list of uncovered lines is over on the right.
For example, lib reservations has 86% statement coverage
and lines 11 and 23 weren't covered by any test.
That same report also generated an HTML version
which goes into much greater detail.
At the top is a summary of the file itself
along with raw statistics like two out of two branches.
The number of times a line has been executed
is shown over on the left.
Areas in red highlight covered code.
Let's take a closer look at each type.
Starting with a statement.
What is a statement?
I'll start off with a link to the Mozilla developer network
on statements for reference and more examples.
A statement performs an action in code.
It may span multiple lines or just be one line.
A statement consists of a group of keywords.
For example, everything in an if else block
is considered a statement.
A declaration of a constant is a statement.
What executes in a while loop is considered a statement.
In the context of this block of code,
the return connects select is considered a statement.
Building on statements are branches.
A branch is each statement within a conditional.
For example, if a condition
then each statement executed as a branch.
So, statement one is a branch and statements two and three
are part of another branch.
Here are some more examples of brand structures.
We've covered if else statements already.
But other conditionals can include logical OR,
logical AND, and the logical NOT operator.
There's also the conditional operator
also known as turnery with a condition,
the ternary operator and one expression or the other.
Here's an example of an uncovered branch.
There's an E symbol, which means the L's is never taken
which in this case is resolving with no errors.
Therefore, this report is from when we didn't test
what happens when validation succeeds.
Uncovered functions are more obvious.
In this case, fetch is never called.
Uncovered lines are also easily recognizable.
So, line 11 is never executed.
Now that we have a better understanding
of what code coverage is and what it looks like.
How can we measure our projects code coverage?