A little bit ago, I had some thoughts about old unit tests, which I posted on Twitter. Rather than restate them, here are the tweets:

dustin king 👽🗽

@cathodion

If
(1) you you can only trust tests you wrote yourself, and
(2) any code older than 6 months may as well have been written by someone else,

..are existing tests actually useful, or do they just double the amount of legacy code per unit of functionality?

16:48 PM - 27 Aug 2018

dustin king 👽🗽

@cathodion

I do find writing unit tests useful in writing new code or stabilizing old code. But often tests are verbose, repetitive, and less readable than the application code.

16:48 PM - 27 Aug 2018

dustin king 👽🗽

@cathodion

So maybe either
(a) all unit tests should be thrown out after a month or so, or
(b) as much care should be put into the usability and maintainability of the tests as the application itself

16:57 PM - 27 Aug 2018

dustin king 👽🗽

@cathodion

or
(c) the author of this thread has trust issues which probably explain a lot

16:57 PM - 27 Aug 2018

Disclaimer: I'm not telling you to throw out all your old unit tests!

However, it has been my subjective experience that pre-existing test suites have caused me as much trouble as they've saved. On the other hand, maybe they prevented even worse problems I wasn't aware of. That's the problem with legacy code, though: you never know what it's okay to change.

Unit tests are often touted as a form of executable documentation. This is only true if they're written for the reader (or at least cleaned up/refactored for them after the fact).

What has your experience with pre-existing test suites been like? Have you encountered a really well-written test suite that lived up to the promise of "executable documentation"? Is there a better way to approach testing and existing tests?