Heads up! To view this whole video, sign in with your Courses account or enroll in your free 7-day trial. Sign In Enroll
Preview
Start a free Courses trial
to watch this video
Code coverage tools can give us an idea of how much of the code has been tested.
Some common code coverage tools for Visual Studio:
For more unit testing techniques, check out Behavior Driven Development.
Related Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign upRelated Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign up
In the previous video,
we considered how much to test.
0:00
Having said all this,
0:04
there are some tools that can help us
to know if we've done enough testing.
0:06
These are called code coverage tools.
0:10
Code coverage tools work with unit test
runners to keep track of how much of
0:13
the code is executed when
the unit test will run.
0:18
There are two types of coverage,
line coverage and decision coverage.
0:21
Line coverage keeps track of which
lines in each file were executed.
0:26
Decision coverage goes even deeper, and
0:30
keeps track to make sure that every
pooling expression in conditionals,
0:33
such as loops and if statements,
evaluate both true and false.
0:37
Just as we have many
unit testing frameworks,
0:42
there are number of code coverage tools.
0:45
Code coverage tools are provided
in Visual Studio Enterprise,
0:47
a commercial version of Visual Studio.
0:51
You can also purchase third party tools
that integrate with Visual Studio,
0:54
such as JetBrains dotCover.
0:58
Other commercial tools are NCover and
NCrunch.
1:01
OpenCover is a free coverage
extension to Visual Studio.
1:04
With all of these coverage tools,
you get what you pay for.
1:09
Code coverage is a bigger topic than
we can cover in this course, but
1:11
I've included links in the teacher's
notes to the tools I've mentioned here,
1:15
if you'd like to learn more.
1:18
Code coverage tools are great, but
1:21
you should be aware that they
may not tell the whole story.
1:23
For example, just because every condition
in the code was evaluated doesn't
1:25
mean that every combination
of conditions was evaluated.
1:30
Just because the code coverage
pool reports that the unit
1:34
test have 100% decision and line coverage,
doesn't mean that testing is complete.
1:38
This is just one metric.
1:43
While we're on the topic of code coverage,
we should discuss testing private, and
1:46
protected members of a class.
1:50
So far,
1:52
we've only been testing by calling the
public members of the class we're testing.
1:53
So you might be thinking,
what about the private and
1:57
protected members and properties?
2:00
There's a simple answer for this.
2:03
Typically, unit testing is only
concerned with testing the functionality
2:05
of the unit, as it's exposed to
the other parts of the program.
2:10
We're testing if the entire class
as a unit works as expected.
2:14
Since other code only interacts with
the class through its public members,
2:19
then that's all we need to test to
verify that it works correctly.
2:23
Private members are considered part of
the implementation details of the class,
2:27
an implementation that's likely to change.
2:31
Protected members, on the other hand,
can only be called from subclasses.
2:35
Since we'll eventually end up writing
unit test for the subclasses,
2:39
we can treat protected members the same
way we treat private members, and
2:43
exclude them from our tests.
2:47
The exception is if we're writing
a library where we expect
2:49
that the users of the library
will write their own subclasses.
2:53
In that case, we need to make sure that
the protected members are well tested.
2:56
This can be done by
creating a mock subclass,
3:01
which can be used to expose the protected
members of the class as public members,
3:04
which can in turn be called by unit tests.
3:09
In general, we don't need to test private
and protected members of a class.
3:12
Code coverage tools should
show that the code of
3:16
all private members is covered by
the test of the public members.
3:19
If parts of the private
members aren't executed,
3:23
then the test should be reviewed to see
how to get better code coverage, or
3:25
perhaps the code in the private
members isn't needed.
3:29
Code coverage is great,
but nothing makes up for
3:33
a good judgement when it
comes to unit testing.
3:36
It's a good idea to have unit test
reviewed by a fellow developer
3:38
that's familiar with the code to make
sure that enough testing has been done.
3:42
You need to sign up for Treehouse in order to download course files.
Sign upYou need to sign up for Treehouse in order to set up Workspace
Sign up