Oops! I was off the grid in the mountains last week, so I queued up a bunch of these to publish, but failed to merge them, so they just sat there. Anyway, here’s what I wrote last week.

A 4-year-old post on HackerNoon is recenlty making the rounds on social media these days, entitled Test-Driven Development is Fundamentally Wrong.

Today I want to respond to it… By agreeing with the author. Surprised?

Okay, but first…

Several years ago I read a book, How to Read a Book. What a silly book idea, right? I mean, who needs a video about how to watch a video, or a course about how to take a course.

Actually, it was a very good book, and it’s improved my ability to read books more effectively since then. One particular lesson I took from the book was to try to come to an understanding, as early as possible, of the definitions the author uses for key words and phrases.

Imagine an author you’re reading says “Roses are blue.”

You have (at least) two options for how to respond:

• “No they aren’t. Roses are red! (or pink, white, black, etc… but never blue!)”
• “Hmm, that’s an unusual thing to say. What would lead you to this conclusion? Let me accept your definition for the duration of this piece of literature, and see if it all makes sense.”

This latter approach is the one I want to take with this “TDD is Fundamentally Flawed” article. Of course I won’t repeat the entire article here, but I will call out some key phrases I agree with:

I always plan my work, starting with requirements and functional specifications, and I have turned down potential clients who didn’t want to take the time to do a design prior to coding.

I think this is a good thing. I mean, sure, one could go too far, and try to write specifications at too granular a level. I don’t know if this author does that or not. But in general, I agree that without knowing what a piece of software should do (“requirements”), you shouldn’t start writing. And without knowing how its going to do it (roughly, “functional specifications”), you also probably shouldn’t start writing. Or at most, you’d write some short experiments to determine what the final functional specification should look like.

And I agree with the author that trying to write your test suite before doing either of these things is a bad idea.

Clients’ designs are always more vague than they realize and even when I am as diligent as I know how to be there will be things that I didn’t think of either.

Yep! 100% on the same page!

Here is what TDD looks like to me:

1. write the TDD tests
2. begin implementation
3. discover an unanticipated consideration
4. rewrite the tests
5. continue implementation
6. goto 3 over and over and over …
7. (actually more like item 150) all tests pass
8. send to QA

Alright… nothing to agree or disagree with here… this is the author explicitly stating his view. I could try to disagree, but that would just make me an ass, for pretending to know the author’s mind better than he does.

Of course, the author’s description of TDD is completely unrelated to the common, accepted definition of TDD, as promoted by folks like Kent Beck. But I’m avoiding the “No, roses are red!” response right now. On the other hand, the author’s understanding of TDD isn’t entirely novel, either. I’ve heard others use a similar “write all your tests up front” definition. So we’re going with that one for the duration of the article.

Note that (4) may happen dozens of times in the course of a large project, and that every single revisit of the TDD tests is 100% wasted time.

Agreed. Rewriting tests like this would be a huge freaking waste of time!

The old way is better

1. begin implementation
2. discover unanticipated considerations and fix them
3. at code-complete write the tests and run them
4. fix any bugs
5. send to QA

Once again, I agree. This way is better than the way than the way described by the author as “TDD”.

But, and maybe this is a crazy idea… what if there were a way that’s even better?

I won’t comment on the rest of the article here, because, frankly, I don’t agree with the rest of it, even after accepting the author’s definitions. And I want to write a post where I agree with someone. LOL