Grabbing for good enough
Uncle Bob, who I consider my favorite programming writer, had a post a few weeks ago titled “Thorns around the Gold“. In it he describes how writing tests for your core functionality first can be harmful. Instead, Uncle Bob prefers to probe for “thorns” around the “gold” first.
I shy away from any tests that are close to the core functionality until I have completely surrounded the problem with passing tests that describe everything but the core functionality. Then, and only then, do I go get The Gold.
I haven’t been doing TDD for nearly as long as Uncle Bob but I was shocked to read this. I’ve always learned and taught that you should create positive tests first, and only need as many negative tests as you feel are warranted. While you may not grab the gold immediately, you at least step towards the gold. How many thorns you expose is a judgement call. In Python, most people don’t even bother validating for None inputs, and instead just let things raise (or not). Of course, this depends on your users. For libraries limited to one internal application, I wouldn’t “probe many hedges.” For open source libraries, I validate pretty aggressively.
Of particular interest was this:
I often find that if all the ancillary behaviors are in place before I approach the core functionality, then the core functionality is much easier to implement.
I always thought you should only program what you need and no more. It seems very strange to assume the ancillary behaviors will be needed. It seems like a violation of YAGNI.
I have been trying to reconcile Uncle Bob’s advice here, and the TDD best practices I’ve learned and developed. But I cannot. Either I’ve been receiving and giving years of bad advice, or Uncle Bob has made a rare mistake.
You should try his technique. It helped me greatly when solving difficult problems. Once you can not think of any of the thorns most of the time you have already solved your problem.
And somehow, most of the time, the code I end up with is much simpler than the code I thought I would write.
I have tried his technique, but often find the opposite. With TDD, I often find the initial approach morphs significantly by the time I am finished. If I start with edge cases, I calcify the often-wrong initial approach.
I have found value in starting out with ‘thorns’ when the problem or structure is more clearly defined (because I’m adding a new class or function to an established system with clear patterns), but still disagree with it when starting anything significant.
Basically, I find proving edge cases a lot less interesting. You learn less. It’s comfortable and easy. For example, it’s often the first thing inexperienced TDD practicioners do. I’d rather jump down a few different critical paths and learn more quickly. If after a few successful tests, I decide removing thorns will make my code better (since I’ve established a way to approach the problem that feels right), I do that. But it is the backup, not the default.