The (oft-misunderstood) dependency inversion principle states that abstractions should not depend on details, and instead details should depend on abstractions. As an example, let us first consider a violation of this guideline: The so-called “abstraction” around configuration ConfigFile is very…
Just for the test of it
Ian Cooper implores you to test behaviors, not implementation details. His video “TDD, where did it all go wrong” expands on these points a bit. The summary is that a bunch of really thorough tests with explicit inner knowledge will…
The testable adapter anti-pattern
Let’s say you’re writing a module to deal with Windows optional features. Following the guidance of the Ports/Adapters/Simulators design approach, you come up with a port IFeatures and an adapter WindowsFeatures. “I must make my adapter testable!” you exclaim, and…
Easier to test => better
Rick Mugridge presented a paper “Test Driven Development and the Scientific Method” at the 2003 Agile Development Conference. There he speaks of theory simplicity and draws a parallel between Occam’s razor and the (positive) pressure of TDD to “choose the…
Code coverage is a legacy metric
In the words of Michael Feathers, legacy code is code without tests. My corollary to this is that code coverage is a legacy metric — best applied to these very same legacy systems with poor, inconsistent, or absent testing practices.…
Zero-One-Infinity (for tests)
The Zero-One-Infinity rule is a computer science adage from Willem van der Poel meant to compel software designers to avoid arbitrary limits. In thinking about this recently, I’ve come to appreciate zero-one-infinity as a useful heuristic for certain categories of…
Wake up again (and again)!
Previously, I wrote about a simple way to change slow, time-sensitive tests into fast, no-wait tests using some async tricks. However, the example shown only works well when the underlying slowness involves a one-shot action. What if instead you are…
Destroy all* tests: unit test edition
Sometimes the code we need to write is so simple that we cannot imagine getting it wrong. Going test-first in these cases just seems apt to lead to tedium and tautologies. This could be a fair point if the sole…
Blogging on logging
Everyone loves a log. A trace log can provide insight into the goings-on of a running system. An audit log gives you an important “paper trail” tracking who did what and when. An error log might be an important aid…
Orchestrating race conditions
Many a programmer has struggled with unit tests and those pesky race conditions that are seemingly immune to them. Is it even possible to verify concurrency correctness using TDD? I am going to tell you that it is — sometimes.…