As mentioned two posts ago, it’s not possible to see new comments made on my old blog. Here’s a comment I received on Tradeoffs.
The basic thrust of the “Tradeoffs” blog post is that code & fix cycles–after development thinks they’re done, and software gets run through a test team–we typically hit a cycle where QA encounters no end of problems that must be fixed.
“I think you’re comparing a project that uses TDD to a project that writes no unit tests until, ‘Done,’ right?
“Why are you ignoring the projects that write unit tests after each
unit is written?
**
“This is faster than both the approaches you describe. It’s faster than TDD because you write far fewer tests that you don’t need and faster than your other (waterfall?) approach because you find problems sooner.”
/Schmoo
Schmoo asks a good question–writing unit tests shortly after a “unit” is written could conceivably be a way of minimizing the code & fix cycle.
I’ve seen it tried, however. In reality, it helps a little, not a lot and not nearly as much as TDD. The code & fix cycle is still there, a bit shorter than it would have been otherwise.
Now, add good automated acceptance tests into the mix, and I believe Schmoo’s premise is closer to true. But unit tests? No. The primary reason is that most test-after-development (TAD) unit tests are insufficient with respect to coverage, particularly in the more complex areas. Why? Check out my earlier blog post, The Realities of Test-After Development.
As far as TDD generating more tests that you don’t need, depends on what your goals are. I’ve found that TDD, which requires you to write tests for just about everything, results in much faster development than TAD, even as TAD produces less coverage. More on these topics in a future blog post.
Comments
Pingback: James Grenning’s Blog
Hi Jeff
This inspired me to write a few more ideas. Take a look here: http://www.renaissancesoftware.net/blog/archives/113
James
thanks James–will take a look at your post in more detail. The formula stuff is interesting. It, as you suggest, is meaningless without real numbers, but I like the idea of mapping it into a proposition that could be verified or disproved more easily someday.
