In TDD, the test suite can serve as a tool for quantitatively analyzing the qualities present (or absent) in the production code.
One example: A test will need to access the production entity that it is testing, obviously. However, sometimes a test needs to access another entity or entities as well, even though they are not currently under test. We sometimes refer to these collectively as a “fixture” for the test.
Some tests have no fixture. The entity in question can be tested entirely on its own. Business rules are often like this. Some tests have a small fixture of an entity or two. Some have large fixtures of many entities.
Fixtures are a measurement of coupling. Look at a given test suite, total the size of the fixtures overall, and divide by the number of tests. This is a measurement of the coupling in the system being tested. Is it large? There is a lot of coupling.
This is not to say that all coupling is bad. But a large average should raise a concern and indicate that coupling is an issue worth looking into.
This is just one example. Tests not only provides a mechanism for analyzing the problem, but also the quality of the solution, and this analysis can be far more concrete than we usually experience. Numbers are numbers.
This is Scott Bain. Visit us at www.netobjectives.com.