P
Phlip
I find debugging a bit too restrictive. I can't just use Undo to make the
bug go >poof<.
Imagine if you had such a button on your debugger! You would hit it all the
time!
You have such a button; it's just a little more expensive than raw code. The
cost savings - no more debugging - overwhelmingly offsets that cost.
And some call it Test First Programming, because TDD is position to replace
the hideous name "eXtreme Programming".
And it doesn't create "unit tests", which are a different topic entirely.
The failure of a unit test implicates only one unit - such as the Ariane V
engine controller.
The failure of a _Developer_ Test implicates the developer's last edit. Time
to hit Undo.
That's not exhaustive.
TDD done well will reduce the _odds_ that you need exhaustive unit testing.
bug go >poof<.
Imagine if you had such a button on your debugger! You would hit it all the
time!
You have such a button; it's just a little more expensive than raw code. The
cost savings - no more debugging - overwhelmingly offsets that cost.
http://www.google.co.uk/search?hl=en&q=behaviour+driven+development&btnG=Google+Search&meta=More fundamentally, TDD is Design Methodology, Not a Testing Methodology.
It just happens to use Unit tests as its means of describing the design,
much like RUP uses UML.
Indeed, some TDD practitioners are starting to call it BDD - as in
And some call it Test First Programming, because TDD is position to replace
the hideous name "eXtreme Programming".
And it doesn't create "unit tests", which are a different topic entirely.
The failure of a unit test implicates only one unit - such as the Ariane V
engine controller.
The failure of a _Developer_ Test implicates the developer's last edit. Time
to hit Undo.
That's not exhaustive.
TDD done well will reduce the _odds_ that you need exhaustive unit testing.