1
00:00:00,490 --> 00:00:04,890
In the previous video we learned that
unit tests demonstrate that the code

2
00:00:04,890 --> 00:00:10,010
written up to a given point is correct and
they give us confidence to move on.

3
00:00:10,010 --> 00:00:11,768
There are many more reasons to unit test.

4
00:00:11,768 --> 00:00:17,100
Unit tests help to discover design
flaws early in the coding process.

5
00:00:17,100 --> 00:00:21,380
Unit test should always be written
by the developer of the code.

6
00:00:21,380 --> 00:00:24,700
Often, when we start coding
we may not be thinking about

7
00:00:24,700 --> 00:00:27,680
all the possible ways
that the code could fail.

8
00:00:27,680 --> 00:00:31,480
There are often corner cases
that we may not have considered.

9
00:00:31,480 --> 00:00:35,448
This can affect how the software
is designed and coded.

10
00:00:35,448 --> 00:00:39,555
When writing unit tests, we're forced to
think about these things and we end up

11
00:00:39,555 --> 00:00:44,680
with a more intimate knowledge of the code
and the problem we're trying to solve.

12
00:00:44,680 --> 00:00:47,730
Unit tests find runtime errors.

13
00:00:47,730 --> 00:00:51,802
Runtime errors can cause the software
to crash or to stop working.

14
00:00:51,802 --> 00:00:57,970
In C# the most common example of a runtime
error is an improperly handled exception.

15
00:00:57,970 --> 00:01:03,030
By testing the code at the unit level, we
can get much better visibility regarding

16
00:01:03,030 --> 00:01:06,680
where exceptions may arise and
how they should be handled.

17
00:01:06,680 --> 00:01:11,179
In scripted and non-compiled languages
such as Python or JavaScript, unit

18
00:01:11,179 --> 00:01:16,038
tests are used to discover coding errors
that could have been caught by a compiler.

19
00:01:16,038 --> 00:01:18,880
Unit tests find logic errors.

20
00:01:18,880 --> 00:01:21,890
Just because the software appears
to work on the surface and

21
00:01:21,890 --> 00:01:24,200
doesn't crash,
doesn't mean that it's correct.

22
00:01:24,200 --> 00:01:28,190
The software may still
produce the wrong output or

23
00:01:28,190 --> 00:01:30,850
display the wrong information to the user.

24
00:01:30,850 --> 00:01:33,700
This is most likely due
to errors in the way that

25
00:01:33,700 --> 00:01:36,280
the logic of the software was coded.

26
00:01:36,280 --> 00:01:39,520
When doing unit tests,
we try to exercise the code

27
00:01:39,520 --> 00:01:44,310
as many different ways as possible by
providing it different sets of inputs.

28
00:01:44,310 --> 00:01:47,600
For each input, we check to see
if we get the expected output.

29
00:01:48,815 --> 00:01:52,285
Unit tests provide multiple
entry points into the code.

30
00:01:52,285 --> 00:01:56,275
The entry point of a piece of software
is where the code starts executing

31
00:01:56,275 --> 00:01:57,475
when it's launched.

32
00:01:57,475 --> 00:02:02,555
For example, the entry point of a console
application is always the main method.

33
00:02:02,555 --> 00:02:05,915
Unit tests give us the ability
to run every unit of code

34
00:02:05,915 --> 00:02:08,355
independently of the rest of the software.

35
00:02:08,355 --> 00:02:11,905
This in essence provides multiple
entry points into the code

36
00:02:11,905 --> 00:02:14,120
that we wouldn't otherwise have.

37
00:02:14,120 --> 00:02:19,510
This makes it very easy to isolate and
debug the code, when we discover problems.

38
00:02:19,510 --> 00:02:22,040
This is especially important
when coding a library,

39
00:02:22,040 --> 00:02:25,130
because libraries don't have entry points.

40
00:02:25,130 --> 00:02:28,210
Unit tests are part of
the documentation of the code.

41
00:02:28,210 --> 00:02:30,670
When working with code,
that you didn't write yourself.

42
00:02:30,670 --> 00:02:34,920
It's important to have some sort of
documentation, to learn how to use it.

43
00:02:34,920 --> 00:02:39,790
If you're lucky, someone will have taken
the time to write some good documentation.

44
00:02:39,790 --> 00:02:42,820
Documentation can be hard
to keep up to date though.

45
00:02:42,820 --> 00:02:47,270
In the absence of good documentation, you
can find examples of how to use the code

46
00:02:47,270 --> 00:02:51,946
by looking at the unit test, provided that
the developer wrote unit tests of course.

47
00:02:51,946 --> 00:02:56,180
Running unit tests is easy to automate
because they are written in code and

48
00:02:56,180 --> 00:02:57,430
saved in files.

49
00:02:57,430 --> 00:03:00,680
They can be run and
re-run as often as we want.

50
00:03:00,680 --> 00:03:02,800
We'll see many examples
of that in this course.

51
00:03:03,920 --> 00:03:08,540
The best developers in the world
regularly make mistakes and that's okay.

52
00:03:08,540 --> 00:03:12,800
Even the most experienced developers
would never overlook testing though.

53
00:03:12,800 --> 00:03:17,390
There's an old saying that claims an ounce
of prevention is worth a pound of cure,

54
00:03:17,390 --> 00:03:20,020
and that is so true for unit testing.

55
00:03:20,020 --> 00:03:23,340
It often shortens the overall
time it takes to finish a product

56
00:03:23,340 --> 00:03:25,410
by building quality in
early in the process.

57
00:03:26,550 --> 00:03:27,510
At the very least,

58
00:03:27,510 --> 00:03:31,810
it reduces the amount of uncertainty
in a project, especially at the end.

59
00:03:31,810 --> 00:03:35,990
With all of these benefits, it's easy
to see why unit testing is a critical

60
00:03:35,990 --> 00:03:37,680
part of the software development process.