
Agile people still don't get it - stesch
http://beust.com/weblog/2006/06/07/agile-people-still-dont-get-it/
======
locopati
Not sure how _I’m fortunate enough to work on a project that lets me use TDD
most of the time._ meshes with _but none of them [agilists] have any
experience what companies whose survival depends on shipping software have to
go through to organize huge code bases_

He admits the benefits of TDD and the next paragraph turns on the proponents
of TDD (which is not all there is to agile, but that's another story).

Every shop I've worked in, I've had to sell TDD, and every time it's been
varying degrees of slog, and at the same time, we've been able to develop
faster: random things weren't breaking since we had tests to catch things like
that (and if things did break, we wrote more tests to catch that too); having
developers leave or hiring new developers were less of a risk because there
were examples of working code and because there were tests to buffer the
learning curve; major refactors were less scary because end-results could
still be validated even if a large part of under-the-hood had changed.

Sure you have to be sane - the one-off prototype doesn't need the same degree
of TDD as the platform that's going to be around for 5 years, but you still
need a way to validate your results. And yeah, sometimes the tests come after
the code, but the tests still need to be there.

------
devicenull
I'd have to agree with some of this. Every example of testing I've found just
covers basic items (like that stack class mentioned here). As far as I can
tell, no one talks about how you should start testing things that actually
have complex code behind them. If I've just managed to miss all the discussion
about testing a very large application, I'd love to know where it was.

------
tzs
_"Somebody in the audience was quick to give a counter-example to this absurd
claim by using a numeric example ('how do you specify an exponentiation
function with a test?')"_

How about a test that picks a bunch of random x values, and calls the function
to get f(x), then checks to see if those perfectly fit an exponential curve?

~~~
jar
A better way to handle this would be to take a set of inputs, run it through
the function and then hand-inspect (or use some other tool to check) that the
results make sense. Store the inputs and outputs in a CSV file.

Now, every time you run the test you should read in this file and compare the
results that you get running the function with the results contained in that
file (which were already verified to be correct.)

This doesn't ensure that the calculations are done correctly, but it does
ensure that after future code changes the output remains consistent.

------
po
This was from June 7, 2006... Maybe we can all hope they get it by now?

