|
| Nick Landsberg wrote:
> What I had philosophical objections to was that
> previous posts by proponents of TDD seemed to
> imply that it would solve all problems. I'm glad
> you clarified that, thanks.
Oookay. Then I come at the same point from a different direction.
If you accept the responsibility to write a line of test that forces every
line of code you need to exist, then you accept the responsibility to
perform sufficient research into your space to learn how to know its needs
cold, without resorting to guessing.
For example, 3d graphics did not appear on the list. But I want to
test-first that an OpenGL image contains a T, with a vertical tube and two
arms sticking out at the top.
This is a  istically hard problem, because OpenGL was written from scratch
to move data in one direction only - from the source code into the display
hardware. From OpenGL's point of view, asking "what did I just tell you to
paint?" is an absurd non-sequitur. 3d programs optimize when the high-level
logic knows exactly what it told OpenGL to paint.
If test-infected programmers had invented OpenGL, it would be just as fast,
but it would be sparklingly easy to TDD. Some spaces are, indeed, harder to
TDD, even from scratch. But every little bit of effort to learn how is
itself a useful kind of research.
> It seems that what you are saying is that that TDD
> is specific to the functional aspects of the application,
> but does not address the "supra"-functional aspects,
> i.e. -
>
>
> Now... how would you propose that methods like TDD
> be applied these aspects? (Serious question.)
By using TDD to implementing the existing algorithms known to address those
things.
The distinction here is between algorithm generation and program
architecture. TDD rapidly solves the latter and resists bugs as a
side-effect.
If you use TDD to try to generate a new algorithm, you are performing
computer science, not software engineering, and all bets are off. TDD works
well on program architecture because TDD makes a process insensitive to
initial conditions. Programmers can accept feature requests in any order.
Designing means reconciling conflicting constraints, and incremental
reconciliation via real code and real tests is the best way yet discovered
to do that.
However, TDD used to generate algorithms is extraordinarily sensitive to
initial conditions. Early refactors, following the "merge duplication"
rules, can lead to code that obscures, not reveals, a more powerful
algorithm later.
Anyone who thinks of a generic algorithm generator is going to be a
trillionaire. TDD is a very good approach, but it's as risky as any other
technique. You won't get bugs, but you might not get a good algorithm.
If I were to implement a given algorithm via TDD, I would look it up in one
of Sedgewick's algorithm books. Then I would start with the simplest
scenario, write a simple test, and write simple code to pass the test. Then
I'd write the next most simplest test, pass it, and refactor the code
towards, not away from, the solution found in the book. I would lead the
tests thru the scenarios Sedgewick presents (and all the intermediate
scenarios that he considered obvious), and refactor until the code matched
his solution.
Note I did not say "TDD is magic, and I don't need to read no stinkin'
Sedgewick books to implement advanced algorithms with it". If I were a
trillionaire, I'd have people to do my USENET posts for me...;-)
--
Phlip
http://industrialxp.org/community/b...tUserInterfaces
|
|