Delet Est

Today I came across a short article titled "You should delete tests", which I largely agree with. However, there’s a sentence early on that I don’t fully agree with:

"Unfortunately, one of those consensus beliefs seems to be 'it is blasphemy to delete a test,' and that belief is not just wrong but actively harmful."

Automated tests are hard to delete — not because of dogma or superstition, but because they’re often poorly written, overly complex, neglected in maintenance, and most importantly: not written using TDD.

Looking back at Kent Beck’s Test-Driven Development: By Example, one of the key ideas is to refactor your tests as you refactor your code. This helps you achieve the minimal set of essential tests: as simple and as precise as possible.

I must admit that, for me, ideal tests are a kind of elusive goal I’ve been chasing for a while — with, let’s say, moderate success. But as with any aspect of growth, it's worth setting goals to improve. So if I had to outline the main principles I try to follow to improve automated tests, they’d be:

• Take the time to write clear and precise names and assertions. They should describe what they’re testing and why they fail (if they do). Unfortunately, when tests are written just to “cover lines of code,” their quality suffers and they become incomprehensible. And if all you know about a test is that it covers a few lines, you’ll never have the confidence to delete or refactor it.

• Avoid duplicated tests. There’s a common habit of testing by layers: first unit tests, then feature tests, then integration tests. Most likely, you’ll end up testing the same thing 2 or 3 times, often in very similar ways. If your feature tests reliably cover the same behavior as the unit ones, it might make sense to remove the latter — reducing maintenance burden and complexity.

And remember: if your tests are clear (as in the first point), it’s easier to avoid duplication. When we inherit messy, unclear tests, we tend to write new ones whenever we change or refactor code — simply out of fear of touching the old ones. This dramatically increases the system’s entropy.

• Be as clear and explicit as possible. Don’t aim for clever abstractions or try to reduce line count at the expense of clarity. Whenever possible, avoid complex test logic that might require testing the tests themselves.

Just by following these three points to some extent, we can achieve meaningful improvements in our testing practices. But in the end, it all boils down to one simple idea:

Take your automated tests as seriously as the code they’re meant to validate.

exit(0);