back
4 comments
An opinion I never hear is that your testing strategy depends on what kind of code you are writing. It is one thing to write a test suite for code that parses strings to objects, it's another thing to write a test suite for a web application where the real problems on your mind are "Why is this off by three pixels on browser X?" or "How can I write CSS that works without peppering !important everywhere?"
As far as I can tell, the XP community pretty quickly converged on "let's use patterns to nope that scope"; for example "The Humble Dialog Box" by Michael Feathers (https://raw.githubusercontent.com/peerreynders/rendezvous/ma...).

(Also, TDD wasn't being hyped as a testing practice, but more of an analysis/design/programming practice: https://users.csc.calpoly.edu/~djanzen/setopics/testing/IEEE... )

Also, in the 90s we talked about tests as another indication of programmer intent. Since we couldn't get developers to document their code and "design as a practice" fell out of favor, tests were the only thing left indicating how the code was intended to be used.

The linked article is a bit wordy, but I think what he's trying to say is: write tests exercising the behavior of interfaces because you may want to change your implementation some day. The drawback of this approach is we don't have a universal way to express Bertrand-Russell-esque contracts on interfaces, so testing behavior when you provide "unsupported" inputs is rather ad hoc.

My take is that one way to make sure that value > cost for tests is to use tests as a form of documentation or to support documentation.

One of the best applications for "literate programming" is to put all the code snippets in the documentation into unit tests. If you don't do that it seems impossible that you could write a book like The C Programming Language and have the examples really work.