Re: TDD: Test-Driven Design or Test-Driven Development?

From: Nick Landsberg (hukolau_at_NOSPAM.att.net)
Date: 02/29/04 

Date: Sun, 29 Feb 2004 22:59:37 GMT

Robert C. Martin wrote:

> On Sun, 29 Feb 2004 17:45:41 GMT, Nick Landsberg
> <hukolau@NOSPAM.att.net> wrote:
>
>
>>
>>Phlip wrote:
>>
>>[SNIP] Other points will be replied to in another
>>post.
>>
>>
>>>If a project has super-high availability needs, you must ask the developers
>>>why they are _not_ writing tests before writing the tested code!
>>>
>>
>>Ahh! I think you may have found the right phrase to
>>enlighten me. What I get from the above sentence
>>is that this technique (TDD) involves writing/documenting
>>all the important test cases *before* starting coding.
>>(Am I correct?)
>
>
> Not quite. Using TDD you start writing tests first, but you don't
> write all of them first. Instead, you write just enough of a unit
> test to fail, then you make it pass by writing production code. Then
> you add to the unit test to make it fail, and then add to the
> production code to make it pass. This is a *very* tight loop that
> spans, perhaps, 1-10 minutes.
>
> At the same time, QA folks and business analysts write acceptance
> tests. These are automated tests written in a very high level
> scripting language (see http://fitnesse.org). These tests are written
> at the beginning of each 1-2 week iteration, and are the final written
> authority for the requirements. Developers receive them very early in
> the iteration and write their unit tests and production code to make
> these acceptance tests pass.
>
>>You are, in fact, proposing a global mind-set
>>change.
>
>
> Yes, it can be very hard to get your arms around.
>
>>To paraphrase:
>>
>>Rule 1: "It ain't a requirement until it's testable!"
>>Corollary 1: "Know all the test cases for this requirement
>>before writing the code."
>
>
> The rule is certainly part of TDD. The corollary is softened to
> "Write the code in conjunction with the tests, allowing the tests to
> lead the way."
>

So, in this model, if one of the QOI requirements is
that "this function shall take no more than 10 milliseconds"
then the inability of the initial attemp to take less than
10 milliseconds would be considered a failure at that
point? I like that!

(BTW: That's real in my world. 10 ms. is allocated
for the *slowest* functions.)

Of course, appropriate tests would have to be
devised for this, and that's all well and good.

This, tho, implies that someone has thought about
these QOI (Quality of implentation) requirements,
done the appropiate math, and has bothered to socialize
them with his/her peers. (This applies to both
performance and stability requirements). All too
often these are "assumed" and/or implied and not
properly conveyed to the development team.
(or is this the subject of yet another discussion?)

Nick L. 

-- 
Ñ
"It is impossible to make anything foolproof because fools are so 
ingenious" - A. Bloch

Relevant Pages

  • Re: TDD: Test-Driven Design or Test-Driven Development?
    ... Using TDD you start writing tests first, ... then you make it pass by writing production code. ... you add to the unit test to make it fail, ...
    (comp.object)
  • Re: dynamic type checking - a pauline conversion?
    ... > unit test for each place in the code anyway. ... and you aren't allowed to write more production code than ... > references 'say' in some instance of T will have a test that checks ... modern statically typed languages and do away with the NULL non-sense. ...
    (comp.object)
  • Re: dynamic type checking - a pauline conversion?
    ... >> And each client will have a unit test that ensures this is not the ... If we are practicing TDD we have a ... and you aren't allowed to write more production code than ... references 'say' in some instance of T will have a test that checks ...
    (comp.object)