Re: case against XP (was: PG: Hackers and Painters)

[Sundar Narasimhan <address@hidden>]

   This article make some good points but was obviously written by
   someone who hasn't tried the approach, particularly in the area
   of test-driven development.  Example:

   "With XP, constant refactoring (i.e. constant tinkering and redesigning 
   of your code) is supposedly possible because the automated tests will 
   catch out any problems. That is, the tests will catch out all the bugs 
   that have been thought of in advance, but no others. Last time I 
   checked, most bugs are due to things that the programmer had not thought 
   of."

   This is what test-driven development looks like from the outside -- as 
   if people wrote unit tests against their complete
   understanding of the application and hence, potentially left things 
   uncovered.  Test-driven development doesn't allow
   a feature to be added to the application code unless it is put in to 
   make a test work.  There is effectively _no_ code
   that doesn't correspond to some unit test or other, so it's not easy to 
   find holes in the test suite.  I know from
   personal experience that refactoring is vastly easier and more reliable 
   when the code has been developed using TDD.

Jerry -- I'm confused. How do you write unit tests say for the
Travelling Salesman Problem :) And even if you did write a couple of
test instances, how does it help you write the code to solve the
problem? (I've seen plenty such codes that handled test suites fine,
but crashed horribly or performed poorly when faced w/ real production
problems).

I just don't get the point about how one can write code driven
*solely* by tests. I think that would be *impossible*, not only
because of bugs that the programmer has not thought of (as the article
says) but also because of most intelligent programs in my experience
are either heavily data or UI driven, and it is simply impossible to
get good coverage of problem instances. Sure, one can use carefully
chosen edge cases to write tests, but ..

Care to explain? (Please note that I am not saying tests are
meaningless or TDD has no applicability -- all I'm saying is that I
find the dogma re. TDD in XP puzzling. Esp. because in my experience
programmers will look where the light is.. and emphasizing tests a bit
too much .. and you'll get a lot of your hours/$$ spent on verifying
your computer can indeed add and subtract numbers. Stated differently,
what percentage of the tests you wrote in TDD/XP were truly
meaningful, or were you somehow smart enough during the initial stages
of a project to write truly useful tests right from the get go :)