Code Leader: Using People, Tools, and Processes to Build Successful Software

4.2. Every Class Has a Test Fixture

Every class in your system should have a corresponding test fixture in your unit-test suite. This is largely an organizational issue, but it is an important one. The easiest way to validate the fact that new code comes with tests is to look for a corresponding test fixture in your test suite. Of course, the addition of a new test fixture to go with a new class doesn't guarantee that the right things are being tested, or that the code is being tested thoroughly, but it is a starting point. This means that not only is at least some form of testing being included, but also that a particular organizational scheme is being followed. If you separate each fixture into its own file, and follow a convention for naming said files (see Figure 4-1), it becomes very easy for everyone on the team to find what they are looking for when correlating test code with code under test.

Figure 4-1. Figure 4-1

I prefer putting test code in a separate assembly/package/library so that it is physically separated from code under test. There is no reason to ship test code to a customer, and the easiest way to keep that from happening is to keep test code in a separate binary file, or however your executable code gets packaged for deployment.

The previous example shows how to consistently name both binary files and classes/files for maximum clarity. There is no need to ...