avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From pe...@realityforge.org
Subject Re: [RT] Adopting XP Practices in Avalon
Date Wed, 30 Jul 2003 01:36:17 GMT

From: "Ulrich Mayring" <ulrich@mayring.de>
> The other XP principles you mentioned are all good, but test-driven
> development is a decoy. You can never catch the hard-to-find bugs and
> simply fixing the trivial bugs, when they occur, is much faster than
> writing formalized tests for them.
...
> The moral is: why worry about formalizing trivialities, just get the job
> done. And you'll never succeed in formalizing non-trivialities, i.e.
> writing tests for hairy bugs.

I don't think you understand the purpose behind TDD. While it is true
that TDD can be used to generate tests for trivial and non trivial code
paths I am not sure thats the primary reason why it is so useful.

One of the central tenets of Agile-style methodologies (of which XP is
just one) is to keep the code base agile and not do any large up front
design - just do enough to get to next step. The problem with this is
that people are not forced to think about even minor design issues like
the API design.

TDD forces developers to think about these issues. You effectively design
and define the contract/API for the functionality with the unit tests and
from
this you have a stub of your final implementation class. So IMHO the best
thing TDD does is force developers to think about the minimal design issues.
TDD often highlights many issues and corrects many "design" bugs before
you write a single line of code.

Traditional development process would have an extensive specification
process to determine the APIs/Contracts of interfaces - XP does not have
this and TDD compensates for this loss. As much as process is a dirty word
to Agile peeps, TDD is effectively a process to ensure a minimal level of
design and thought has gone into the system.

Another significant advantage of TDD is that it tends to produce code that
is highly testable. This is very desirable - even if the code is never
actually
unit tested. The reason is that testable code is often well factored, simple
and much more easier to maintain due to its focus.

The fact that TDD produces extensive unit tests is great and even essential
to Agile to ensure reliability in face of massive refactoring. However I
don't
think this is as important as the above "features" of TDD.

Once people adopt TDD I have found that it actually decreases the time to
develope. Mainly as the people
a) think about the code and the contract
b) write code that is focused/testable
c) have unit tests to make sure that the implementation matches their
    assumptions

It also helps later in the development cycle by reducing chance of
incompatible changes. No unit tests should be an effort to write -
even for trivial bugs. In fact the unit tests should be the fastest way
to locate bugs (trivial or not). If this is not the case then you probably
did not develope code using TDD.

TDD is no magic bullet (in fact it ofen makes people think too "locally"
when
they should be thinking "globally") but I would not dismiss it if I were
you.



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Mime
View raw message