TDD is BS?

H. S. Teoh hsteoh at quickfur.ath.cx
Wed Jun 19 20:25:41 PDT 2013


On Thu, Jun 20, 2013 at 03:15:54AM +0200, Chris Cain wrote:
[...]
> TDD (Test Driven Development) has a terrible name. Too many people
> think it's about the tests. Tests are certainly a good side effect
> of TDD and I certainly can't suggest they don't have value, but the
> fact that tests are written is really irrelevant to what you are
> _really_ trying to get out of TDD. There's been numerous attempts to
> rebrand it (Test Driven Design, Behavior Driven Development, and
> Behavior Driven Design to name a few).
> 
> Ultimately, the "goal" of TDD is to have the programmer sit down and
> look at code from a USER'S (as in, user of the API) point of view
> _FIRST_. "Writing a test" as the first step is really just
> suggesting "as a user, how would you find it convenient to use this
> thing?" That's really just about all there is to it. It's one of
> those things that helps guide your thought process. If you're
> already doing that without writing tests first, then great. I've
> always found it pretty helpful to play around with how I want code
> to look like before I actually code the implementation details,
> though. More often I can come up with a simpler and more robust
> design after playing with how I want the end result to look like. As
> a cool bonus, once everything is done, you'll have a "specification"
> showing all of the features of a class/package/module and how
> everything is used. It will also show what kinds of preconditions
> are necessary for using those things (for instance, does your class
> need particular services to be online for it to work? If so, it'll
> show up in the tests).
[...]

Thanks for your clarification! This is much more helpful than the
definitions of TDD that I found online (e.g. on Wikipedia).

I will say, though, that this seems to be just Yet Another Buzzword for
"API design". (I'm automatically skeptical when buzzwords are involved,
because all too often, buzzwords are employed to make something rather
ordinary appear to be special.) I agree that many APIs are poorly
designed because the implementors were more concerned with the
implementation, rather than how the users will be using it through the
API.

OTOH, not all APIs should be designed to cater to the users' POV. I've
encountered APIs that were *not* "convenient" in the way that I had
preconceived, but in the end, it turned out that by forcing me to do
things the "inconvenient" way, it not only opened up brand new ways of
thinking about the problem, but also guided me into approaching the
problem from an angle that is *efficient to implement*. It's just like
Knuth said:

	"People who are more than casually interested in computers
	should have at least some idea of what the underlying hardware
	is like. Otherwise the programs they write will be pretty
	weird."

So I think a balance needs to be struck between what users would like it
to be, vs. what is a good way of approaching the problem.  API's should
not be so far removed from their implementations that the resulting code
becomes "pretty weird", as Knuth puts it. TDD is good and all, but
there's the danger of pushing it too far and applying it where it's not
applicable.


T

-- 
Obviously, some things aren't very obvious.


More information about the Digitalmars-d mailing list