Don’t listen to your tests

“Listen to your tests”. Such good advice! If you haven’t encountered the phrase before, it means:

If it’s hard to write a test you should reconsider the design of your code.

I wish people took the time to say that instead of just a curt “Listen to your tests” (henceforth LTYT). The problem with LTYT is that it’s often misconstrued; although it’s advice about TDD, it’s incorrect to assume that knowledge of TDD is sufficient to apply it. In order to effectively LTYT, you need a lot of knowledge and experience in the area of software design.

Consequently, when TDD experts say “listen to your tests” to junior developers, what the latter hear is often one of these things:

• If I think about my tests hard enough, I’ll know how to design my code.
• I know my tests are messy, but I have no idea how to fix them. This is supposed to be obvious. I guess I’m just not smart enough.
• Oh, I know, I’ll use an event bus!

But these interpretations are incorrect! No matter how good you are at red-green-refactor, TDD by itself will never tell you what tests to write. It will not tell you what boundary to test at. It will not teach you about the single-responsibility principle or the law of Demeter. TDD can tell you when your design is bad, but it will never tell you which other designs might be good.

Don’t listen to your tests! Tests can’t talk! They can, at best, emit a high-pitched whine that may induce you to go pick up Head-First Design Patterns or some other such resource. When doing TDD, it is perfectly sufficient to hear your tests complain, and reserve listening for things that can actually teach you how to improve the design of your code.

Next: It turns out I don't like blogging

Previous: How to write a while loop in a functional language