We looked at using unittest and doctest to create automated unit tests. We also looked at creating a test suite so that collections of tests can be packaged for reuse and aggregation into suites with larger scopes, without relying on the automated test discovery process.

We looked at how to create mock objects so that we can test software units in isolation. We also looked at the various kinds of setup and teardown features. These allowed us to write tests with complex initial states or persistent results.

The FIRST unit test properties fit well with both doctest and unittest. The FIRST properties are as follows:

• Fast: Unless we write egregiously bad tests, the performance of doctest and unitest should be very fast.
• Isolated: The unittest package offers us a mock module that we can use to isolate our class definitions. In addition, we can exercise some care in our design to ensure that our components are isolated from each other.
• Repeatable: Using doctest and unittest for automated testing ensures repeatability.
• Self-validating: Both doctest and unittest bind test results with the test case condition, ensuring that no subjective judgment is involved in testing.
• Timely: We can write and run test cases as soon as we have the skeleton of a class, function, or module. A class whose body has simply pass is sufficient to run the test script.

For the purposes of project management, a count of written tests and passed tests is sometimes a very useful status report.