Testing is a whole topic in itself and many books, blogs, and websites are dedicated to it. The testing field has changed a lot since the beginning of the century: the testing industry evolved from manual validation (sometimes with even no test plan), to a heavily automated process. Automation is great in testing because it allows us to execute many tests in very little time. So, automated tests can be executed more often (on each commit instead of each release, for example). As a consequence, bugs are detected more rapidly, and fixing them is easier. At the end, the product is better and the developer can spend more time implementing new features.

Testing can mean many different things because there are different kinds of test:

• Unit tests verify that each function of the application works as expected
• Integration tests verify that the application works correctly with the other components it depends on
• System tests verify that the application works when being deployed

This chapter is dedicated to unit tests, for three reasons:

• This is the first level in the testing chain. So it means that any bugs found in this step cost less to fix than in the other testing phases. The earlier, the better. So all bugs detected with unit tests save time and money.
• The Python standard library contains a module dedicated to this kind of testing.
• With functional programming, unit tests can cover a big part of the application logic. So a good code coverage with unit tests can sometimes detect bugs that would be seen in system tests with other programming paradigms. The following figure shows the bug cost curve depending on when bugs are detected:

Unit tests are, by design, autonomous tests. So they can be executed easily by the developer during coding sessions, but also automatically in a continuous integration process. The five principles of unit tests are the following, abbreviated as F.I.R.S.T:

• Fast: Executing unit tests is fast. They must take, at most, a few seconds so that they can be executed during code development.
• Independent: Unit tests are independent of each other.
• Reproducible: Given the same code as input, a unit test always provides the same result.
• Self-Validating: A unit test indicates whether it passed or failed.

• Timely: Tests are written when appropriate, ideally before implementing the functionality. This principle comes from the TDD methodology, but is very accurate—writing a test before the feature allows us to check that the test fails when the feature does not work.