Care and Feeding of a Test Suite

Consider that your test suite is the actual asset in software development. That is, the tests are more valuable than the code; but the code itself is still essential. 

The test suite is an expression of the desired state of the software. It tells us what the system is supposed to do, but not necessarily how. This is, of course, true at many levels. Microtests tell us specifically what a function does and should encompass all of the behavior of that function. Larger tests should tell us how a collection of functions, or an object should behave. Composed tests should tell us how a collection of objects interact, integration tests how those objects interact with other resources. How the internals work below the level of the test aren't important in terms of the asset. 

Granted, I tend to think of systems of software as a collection of both the deployable software and the test suite that comes with it. So I'm not trying to suggest that the deployed code doesn't matter or shouldn't be well crafted or anything like that. But I am trying to suggest that the test suite is more vital than the code itself in terms of its value to the organization.

The tests are the living breathing embodiment of what is supposed to be true. Without them, the rest of it, no matter how elegant and well polished is a fixed state with no explanation. The tests tell us what is really important. 

As a consequence of the tests importance I think that should guide us in how we develop and maintain test. That is, we should treat the code within the tests with at least as much respect as the code under test. I think there are a few different rules that should be applied to the tests, but we should still attempt to apply a level of craft to the code. By that I mean observing all the same rules we would with our production code and then some. 

I hope to write more about those rules over the next few days.