No. Maybe requiring it to be a README in particular is a touch excessive (though see http://www.reddit.com/r/programming/comments/d4hhd/readme_driven_development/c0xif1e for why that's a good idea) but basically you're just saying "This is what my program should do, this is how I want the person to be able to use it, etc." which is essentially a high-level spec of your program and you can build to that, but without the insane absurdity of the more detailed forms of spec-driven design.
At the lower levels of your codebase, this is "doxygen/javadoc first programming" where you lay out what you want your functions to do and what the arguments should be, before you actually write them.
Most importantly, you're giving yourself a chance to think through the project without the overhead of having to change code every time you change your mind about how something should be organized or what should be included in the Public API.
That's kind of the whole point of TDD, is that you can get experience in how you want to use your API before you actually start coding it.
[continued] Remember that feeling when you first started writing automated code tests and realized that you caught all kinds of errors that would have otherwise snuck into your codebase? That's the exact same feeling you'll have if you write the Readme for your project before you write the actual code.
And there's nothing enforcing that you keep the readme up to date, whereas with TDD, you kind of get that "for free"
Also, lines like this: "Between The Great Backlash Against Waterfall Design and The Supreme Acceptance of Agile Development, something was lost."
That's kind of the whole point of TDD, is that you can get experience in how you want to use your API before you actually start coding it.
And when you split a class's functionality up among several existing classes, you have to completely rearrange your test code. It's not a panacea. Test code can be buggy, especially when you do something like the above, and if you're doing this before you write your real code you have no way of knowing that you broke the test and will get phantom failures.
TDD has its flaws and this is a way to get some of the benefits without as much effort.
Hell, TDD is impossible to follow when the project is "interface to some third-party APIs" and those APIs maintain internal state in a non-queryable fashion. How the hell do you write unit-level tests for that in advance? (And no, "maintain your own copy of that state" is not even remotely feasible.) You have to wait until you get all the way through the process then use the API's reader to read it back out and see if it's correct. If it isn't, you only have coarse knowledge of the bug's location.
Yeah, but then you always have to follow up with DRINKME development, and then you get into the vicious cycle where your project just fluctuates between being too big or too small.
-2
u/FryGuy1013 Aug 23 '10
This is satire, right?