Every software project that's deployed suffers from bugs that are inevitable--and bugs are time and money consuming.

Using a Test-Driven Development (TDD) approach, where you write tests alongside the code you are creating, will not always improve the quality of your project, but it will make your team more agile. This means that the developers who need to fix a bug, or refactor a part of an application, will be able to do a faster and better job when relying on a battery of tests. If they break a feature, the tests should warn them about it.

Writing tests is time-consuming at first, but in the long run, it's often the best approach to make a project grow. Of course, it's always possible to write bad tests and end up with poor results, or create a test suite that's horrible to maintain and takes too long to run. The best tools and processes in the world won't prevent a sloppy developer from producing bad software:

Software industry has long debated on the virtues of TDD. But in the last decade, most of the research papers that tried to measure the benefits of TDD concluded that software built with it costs less money in the long term, and is as good, or better, in terms of quality. This page links to a few research papers on this topic at http://biblio.gdinwiddie.com/biblio/StudiesOfTestDrivenDevelopment.

Writing tests is also a good way to get some perspective on your code. Does the API you've designed make sense? Do things fit well together? And when the team grows or changes, tests are the best source of information. Unlike documentation, they should reflect what the current version of the code does.

But documentation is still an important part of a project even though it's hard and time-consuming to maintain. It's the first stop for anyone using your software or joining the team to work on it. How is the application installed and configured? How to run tests or add features? How is it designed the way it is, and why?

After a while, it's pretty rare to see a project's documentation fully up-to-date with what the code has become unless some dedicated people work on it. And it can be an immense frustration for developers to find out that the code examples in the documentation are broken after some refactoring. But there are ways to mitigate these issues; for instance, code extracts in the documentation could be part of the test suite to make sure they work.

In any case, no matter how much energy you spend on tests and documentation, there's one golden rule: testing, documenting, and coding your projects should be done continuously. In other words, changes in the code should ideally be reflected in the tests and documentation as they happen.

After providing a few general tips on how to test in Python, this chapter focuses on what testing and documentation tools can be used in the context of building microservices with Flask, and how to set up continuous integration with some popular online services.

It's organized into five parts:

• The different kind of tests
• Using WebTest against your microservice
• Using pytest and Tox
• Developer documentation
• Continuous integration