And this is a great example of how religious/fundamentalist TDD sounds to non believers.
Let me briefly summarize the above two comments. "We want our code to be modular, composable, and reusable therefore ... you should write your tests before you write your implementation".
Notice the logical leap? Notice the near obsession with the pieces of this phrase that isn't the important part? And tell someone you don't write your tests first and prepare for looks of disgust thrown your way, a public shaming. And Bob himself does this.
> If you aren't doing TDD, or something as effective as TDD, then you should feel bad.
I see where you're coming from, totally. I personally have moved to thinking about writing tests concurrently. That is, maybe a bit before, maybe a bit after, but as a first-class development effort worthy of "real" developer time and not a half-assed afterthought that is delegated to "lesser" team members.
I don't throw around looks of disgust or shame people, but I insist that in 2014, if you don't have meaningful test automation, you don't have much credibility.
Here's the crux of my argument, quality code is not a function of the number of tests. I tried real TDD 5 years ago and I can assure you code I write today (with less tests) is better than the more tested code I wrote 5 years ago.
This means that there is not a clear correlation between number of tests and clean code, yet that is the central premise of the testing religion.
I like to say that the tests are the first client :)