4 ms·

Agile people still don't get it

12 points by stesch 16y ago

tzs 16y ago
"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?
- prospero 16y ago
  The test function would just be a mirror of the function itself, then. What does that accomplish?
- jar 16y ago
  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.
locopati 16y ago
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 16y ago
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.
po 16y ago
This was from June 7, 2006... Maybe we can all hope they get it by now?

12 points by stesch 16y ago

tzs 16y ago

"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?

prospero 16y ago
The test function would just be a mirror of the function itself, then. What does that accomplish?
jar 16y ago
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.

locopati 16y ago

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 16y ago

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.

po 16y ago

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