In the previous video we learned that unit tests demonstrate that the code

written up to a given point is correct and they give us confidence to move on.

There are many more reasons to unit test.

Unit tests help to discover design flaws early in the coding process.

Unit test should always be written by the developer of the code.

Often, when we start coding we may not be thinking about

all the possible ways that the code could fail.

There are often corner cases that we may not have considered.

This can affect how the software is designed and coded.

When writing unit tests, we're forced to think about these things and we end up

with a more intimate knowledge of the code and the problem we're trying to solve.

Unit tests find runtime errors.

Runtime errors can cause the software to crash or to stop working.

In C# the most common example of a runtime error is an improperly handled exception.

By testing the code at the unit level, we can get much better visibility regarding

where exceptions may arise and how they should be handled.

In scripted and non-compiled languages such as Python or JavaScript, unit

tests are used to discover coding errors that could have been caught by a compiler.

Unit tests find logic errors.

Just because the software appears to work on the surface and

doesn't crash, doesn't mean that it's correct.

The software may still produce the wrong output or

display the wrong information to the user.

This is most likely due to errors in the way that

the logic of the software was coded.

When doing unit tests, we try to exercise the code

as many different ways as possible by providing it different sets of inputs.

For each input, we check to see if we get the expected output.

Unit tests provide multiple entry points into the code.

The entry point of a piece of software is where the code starts executing

when it's launched.

For example, the entry point of a console application is always the main method.

Unit tests give us the ability to run every unit of code

independently of the rest of the software.

This in essence provides multiple entry points into the code

that we wouldn't otherwise have.

This makes it very easy to isolate and debug the code, when we discover problems.

This is especially important when coding a library,

because libraries don't have entry points.

Unit tests are part of the documentation of the code.

When working with code, that you didn't write yourself.

It's important to have some sort of documentation, to learn how to use it.

If you're lucky, someone will have taken the time to write some good documentation.

Documentation can be hard to keep up to date though.

In the absence of good documentation, you can find examples of how to use the code

by looking at the unit test, provided that the developer wrote unit tests of course.

Running unit tests is easy to automate because they are written in code and

saved in files.

They can be run and re-run as often as we want.

We'll see many examples of that in this course.

The best developers in the world regularly make mistakes and that's okay.

Even the most experienced developers would never overlook testing though.

There's an old saying that claims an ounce of prevention is worth a pound of cure,

and that is so true for unit testing.

It often shortens the overall time it takes to finish a product

by building quality in early in the process.

At the very least,

it reduces the amount of uncertainty in a project, especially at the end.

With all of these benefits, it's easy to see why unit testing is a critical

part of the software development process.