Re: TDD sucks [Was: 'Snake Oil']

Phlip wrote:
> hansewetz wrote:
>
> > What are its weaknesses?
>
> TDD is both a low-level design technique and a high-level requirements
> analysis technique.
>
> The low-level technique, used incorrectly or in isolation, can cause big
> trouble. TDD alternates between making simple edits to pass tests with poor
> structure, and refactoring to improve the structure and emerge a design.
> Without the refactoring step, passing tests will push code quality straight
> down and leave it there. Worse, frequent testing now supports this low
> quality, so it resists both bugs and new features.
>
> TDD lowers the cost of each test case by running them frequently. Suppose
> you TDD a fractal, and discover the leaves of this fractal can fail their
> tests due to small variations in floating point rounding error. A more
> expensive test could vary the tolerance based on a leaf's distance from the
> root. A cheap test simply fails if you refactor didn't strictly preserve
> behavior. Hence, go for the cheap test, and use Undo if it fails. The test
> was hyperactive, but running the tests often reduced the cost of each test
> case.
>
> If you don't run the tests frequently, you increase their cost, and they
> start "preventing new features".
>
> The requirements analysis technique (the FIT stuff) makes a project
> sensitive to the steering hand of a real Customer Liaison. Without one, a
> project will fishtail around. I'm unaware of a methodology that works
> without customers; TDD channels the Missing Customer problem into incoherent
> requirements and scattered code modules.
>
> I don't know of a real TDD weakness. All these problems are strengths when
> they balance the weaknesses of other best practices, such as pair
> programming.
>
> > When/where is it not applicable to use?
>
> I can think of only one situation where writing the test before the tested
> code would be a bad thing. When programming a GUI, your GUI Toolkit's main
> job is to decouple appearance from behavior. When you edit a button's
> location, and move it from here to there, you don't need to edit the source
> code that responds to that button. Hence, using test-first to move the
> button is an empty victory. Don't TDD minor "authored" details in GUI code.
>
> Other than that, the inability or reluctance to write the test first
> probably illustrates a problem with your project. That problem needs more
> tests to boost its visibility and manage its risk.
>
> Next comes the question whether designs should be planned or emerged. If a
> project has unique requirements, such as robustness, this should seem to
> indicate its design should have the highest possible level of "design for
> testing". If you plan a design without planning its tests, you risk reducing
> that. If you plan a design with its tests, then you are modeling TDD...

Thanks.
Even though I have certain issues with TDD I appreciate a straight
forward answer.

Regards,
Hans Ewetz

.