TDD is BS?

[Nick Sabalausky]

On Thu, 20 Jun 2013 00:15:50 +0200
"Szymon Gatner" <noemail at gmail.com> wrote:

> On Wednesday, 19 June 2013 at 21:59:21 UTC, Jonathan M Davis 
> wrote:
> >
> > I _do_ agree with writing the tests fora function as soon as 
> > the function is
> > done, in which case, you're likely going to have to do more 
> > work on the
> > function, since it'll probably fail the test, and you'll 
> > probably improve the
> > tests some more at that point as well. But I completely 
> > disagree with writing
> > the test before the code, which is one of the key features of 
> > TDD as its
> > always been explained to me.
> 
> It forces you to think about parameters it should take 
> and value(s) it should return first.

TBH, I've never found a lot of value in that. What I find "write tests
first" does is force you to *guess* about params and return values.
In my experience, implementation automatically roots out the necessary
set of ins and outs.

> 
> API change cost is way higher than fixing a bug inside a function 
> or a class


I very much disagree with that, unless you're talking about "write
implementation, use it everywhere, do a big public release, and *then*
write unittests", which is a bad thing to do anyway. Fixing a bug can
often be non-trivial, but changing an API right after, or while, you're
implementing it is always trivial (although it's less trivial if you've
already written a lot of tests that rely on it).

> also you will often realize that what you initially 
> though was necessary turns out not to be after all.
> 

Like I said above, I find that writing the implementation does a far
better job of that then making guesses about what will/won't be
necessary before implementing.