On Wednesday, 19 June 2013 at 21:54:04 UTC, Walter Bright wrote:
On 6/19/2013 4:01 AM, Szymon Gatner wrote:
This is not strictly D related but I am very curious about D's
community opinion
on the points made by non other than Jim Coplien here:
TDD strikes me as an ad-hoc way of constructing code, and is a
poor substitute for thinking about the problem as a whole. For
example, I don't really see how getting a square root function
to pass its test cases is going to lead one to implementing one
of the classic algorithms for computing square roots. I don't
see how TDD for a compiler will lead one to rediscover what is
known about the best way to organize the logic of a compiler.
TDD is "curve fitting" which is what one does when one has no
understanding.
D's support of unit testing is not an endorsement of TDD.
Point of TDD for a square root function would be to create a good
API for getting a square root of a number. Implementation is just
a detail. Good class design is way harder to achieve then correct
implementation. Libraries become unusable in time not because
they did what they did wrong but because they were badly
structured / designed.
TDD claims to help with this by forcing you to code client code
first (the test) which arguably leads to better decoupling of
components. You don't have to split components for reuse later
because they are already being used in unrelated contexts in
tests.
