1
00:00:00,870 --> 00:00:04,840
In the previous video,
we considered how much to test.

2
00:00:04,840 --> 00:00:06,156
Having said all this,

3
00:00:06,156 --> 00:00:10,536
there are some tools that can help us
to know if we've done enough testing.

4
00:00:10,536 --> 00:00:13,530
These are called code coverage tools.

5
00:00:13,530 --> 00:00:18,227
Code coverage tools work with unit test
runners to keep track of how much of

6
00:00:18,227 --> 00:00:21,351
the code is executed when
the unit test will run.

7
00:00:21,351 --> 00:00:26,370
There are two types of coverage,
line coverage and decision coverage.

8
00:00:26,370 --> 00:00:30,801
Line coverage keeps track of which
lines in each file were executed.

9
00:00:30,801 --> 00:00:33,207
Decision coverage goes even deeper, and

10
00:00:33,207 --> 00:00:37,471
keeps track to make sure that every
pooling expression in conditionals,

11
00:00:37,471 --> 00:00:41,200
such as loops and if statements,
evaluate both true and false.

12
00:00:42,820 --> 00:00:45,397
Just as we have many
unit testing frameworks,

13
00:00:45,397 --> 00:00:47,720
there are number of code coverage tools.

14
00:00:47,720 --> 00:00:51,372
Code coverage tools are provided
in Visual Studio Enterprise,

15
00:00:51,372 --> 00:00:54,590
a commercial version of Visual Studio.

16
00:00:54,590 --> 00:00:58,560
You can also purchase third party tools
that integrate with Visual Studio,

17
00:00:58,560 --> 00:01:01,150
such as JetBrains dotCover.

18
00:01:01,150 --> 00:01:04,442
Other commercial tools are NCover and
NCrunch.

19
00:01:04,442 --> 00:01:09,160
OpenCover is a free coverage
extension to Visual Studio.

20
00:01:09,160 --> 00:01:11,910
With all of these coverage tools,
you get what you pay for.

21
00:01:11,910 --> 00:01:15,086
Code coverage is a bigger topic than
we can cover in this course, but

22
00:01:15,086 --> 00:01:18,877
I've included links in the teacher's
notes to the tools I've mentioned here,

23
00:01:18,877 --> 00:01:20,290
if you'd like to learn more.

24
00:01:21,500 --> 00:01:23,073
Code coverage tools are great, but

25
00:01:23,073 --> 00:01:25,654
you should be aware that they
may not tell the whole story.

26
00:01:25,654 --> 00:01:30,208
For example, just because every condition
in the code was evaluated doesn't

27
00:01:30,208 --> 00:01:34,610
mean that every combination
of conditions was evaluated.

28
00:01:34,610 --> 00:01:38,890
Just because the code coverage
pool reports that the unit

29
00:01:38,890 --> 00:01:43,680
test have 100% decision and line coverage,
doesn't mean that testing is complete.

30
00:01:43,680 --> 00:01:44,960
This is just one metric.

31
00:01:46,300 --> 00:01:50,410
While we're on the topic of code coverage,
we should discuss testing private, and

32
00:01:50,410 --> 00:01:52,510
protected members of a class.

33
00:01:52,510 --> 00:01:53,440
So far,

34
00:01:53,440 --> 00:01:57,960
we've only been testing by calling the
public members of the class we're testing.

35
00:01:57,960 --> 00:02:00,870
So you might be thinking,
what about the private and

36
00:02:00,870 --> 00:02:03,100
protected members and properties?

37
00:02:03,100 --> 00:02:04,440
There's a simple answer for this.

38
00:02:05,660 --> 00:02:10,000
Typically, unit testing is only
concerned with testing the functionality

39
00:02:10,000 --> 00:02:13,370
of the unit, as it's exposed to
the other parts of the program.

40
00:02:14,370 --> 00:02:19,010
We're testing if the entire class
as a unit works as expected.

41
00:02:19,010 --> 00:02:23,230
Since other code only interacts with
the class through its public members,

42
00:02:23,230 --> 00:02:27,340
then that's all we need to test to
verify that it works correctly.

43
00:02:27,340 --> 00:02:31,770
Private members are considered part of
the implementation details of the class,

44
00:02:31,770 --> 00:02:33,990
an implementation that's likely to change.

45
00:02:35,190 --> 00:02:39,510
Protected members, on the other hand,
can only be called from subclasses.

46
00:02:39,510 --> 00:02:43,470
Since we'll eventually end up writing
unit test for the subclasses,

47
00:02:43,470 --> 00:02:47,340
we can treat protected members the same
way we treat private members, and

48
00:02:47,340 --> 00:02:48,610
exclude them from our tests.

49
00:02:49,920 --> 00:02:53,180
The exception is if we're writing
a library where we expect

50
00:02:53,180 --> 00:02:56,900
that the users of the library
will write their own subclasses.

51
00:02:56,900 --> 00:03:01,620
In that case, we need to make sure that
the protected members are well tested.

52
00:03:01,620 --> 00:03:04,490
This can be done by
creating a mock subclass,

53
00:03:04,490 --> 00:03:09,140
which can be used to expose the protected
members of the class as public members,

54
00:03:09,140 --> 00:03:11,160
which can in turn be called by unit tests.

55
00:03:12,460 --> 00:03:16,960
In general, we don't need to test private
and protected members of a class.

56
00:03:16,960 --> 00:03:19,500
Code coverage tools should
show that the code of

57
00:03:19,500 --> 00:03:23,060
all private members is covered by
the test of the public members.

58
00:03:23,060 --> 00:03:25,430
If parts of the private
members aren't executed,

59
00:03:25,430 --> 00:03:29,740
then the test should be reviewed to see
how to get better code coverage, or

60
00:03:29,740 --> 00:03:31,870
perhaps the code in the private
members isn't needed.

61
00:03:33,360 --> 00:03:36,060
Code coverage is great,
but nothing makes up for

62
00:03:36,060 --> 00:03:38,780
a good judgement when it
comes to unit testing.

63
00:03:38,780 --> 00:03:42,660
It's a good idea to have unit test
reviewed by a fellow developer

64
00:03:42,660 --> 00:03:46,160
that's familiar with the code to make
sure that enough testing has been done.