Return to Answer

Wow!

"Testing" questions are bound to attract tons of opinions. And — lo and behold — you've gotten a ton of opinions. The truly great thing about questions like this (that draw lots of opinions) is the clarity with which they prove that there is no "one right way" to build software.

Let me give you a very light framework for making this decision — and then I'll give you my own opinion. (One that I like to think is well-founded!)

I have a little more context in my original article here, but in summary: If you don't understand reasonably well how the behaviors you're taking (principle, pattern, practice, etc.) lead definitively to the higher-level outcome you need, there is virtually no way for you to correctly put the behaviors into practice — even if they are "the right behaviors."

"Testing" questions are bound to attract tons of opinions. And — lo and behold — you've gotten a ton of opinions. The truly great thing about questions like this is the clarity with which they prove that there is no "one right way" to build software.

Let me give you a very light framework for understanding the mechanisms at play when implementing a discipline like this — and then I'll give you my own opinion.

I have a little more context in my original article here, but in summary: If you don't understand reasonably well how the behaviors you're taking (principle, pattern, practice, etc.) lead definitively to the higher-level outcome you need, there is virtually no way for you to correctly put the behaviors into practice — even if they are "the right behaviors."

Essentially, how you understanding a practice dictates the outcome and the mechanism by which the outcome is achieved (or not).

If your product is conducive to this, the more "contractual" a test is, the more it should look like a regular customer interaction. But, the more non-negotiable essence of this is that your most important/contractual tests should be written in a manner that is easy to parse with human eyes, ideally by your manager, product owner, etc., so they can actually participate in the code review and click the "approve" button.

Ideally, the more "contractual" a test is, the more it should look like a regular customer interaction. Some products may not really "fit" that mental model. But, at the very least, your most important/contractual tests should be written in a manner that is easy to parse with human eyes, ideally by your manager, product owner, etc., so that these people can meaningfully participate in the code review process and click the "approve" button.

What the additional testing did not do: Enforce "code quality". The code needed to be testable enough; but there's plenty of debt still hanging around that repo. Maybe someday someone will clean it up. If they do, it will be difficult for them to break the code's customer-facing contracts.

But, we didn't use testing to improve code quality. That wasn't its purpose. We used it to define and stabilize the contracts with our customers.

What the additional testing did not do: Enforce "code quality". The code needed to be testable enough; but there's plenty of debt still hanging around that repo. And that's expected. We didn't ask the testing discipline to improve code quality. We asked it to define and stabilize the contracts with our customers.

And, that's what it does.