|
Listen to this post
|
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.