I suspect that the typical approach to testing produces more brittle production systems.

I intuit that we’re far less likely to “scout" what we perceive to be ‘test code’ than ‘production code’.

I see a lot of idea duplication in tests, the kind that we would avoid in production. Are we less likely to design structure for our tests than for the rest of the code? For example, I’ve seen testing capabilities implemented as TestCase base classes or traits. These are both approaches that we eagerly avoid in ‘production code’.

I wonder if the idea of ‘production code’ is a useful model. What we end up deploying to production are systems, and tests are one of the most important ways in which we interact with these systems.

We put effort into making our code as comprehensible as possible. I don’t perceive the same diligence of design in test suites. I perceive the consequences are:

  • slower test development - reimplementation of fixtures, assertions, etc
  • less maintainable tests - redundancy in code implementation makes refactoring difficult.. when refactoring we might have to 100 test-oriented classes that implement redundant behavior
  • less comprehensible tests - those redundancies accumulate into messy code that obscures the intended test

In my work, I’m going to continue asking, “are we scouting our test code with the same diligence as the rest of the system?".