This course will be retired on July 14, 2025.
Heads up! To view this whole video, sign in with your Courses account or enroll in your free 7-day trial. Sign In Enroll
Well done!
You have completed Unit Testing in C#!
You have completed Unit Testing in C#!
Preview
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