Re: how many bugs do you find and correct during TDD?

From: Nick Landsberg (SPAMhukolauTRAP_at_SPAMworldnetTRAP.att.net)
Date: 12/31/04 

Date: Fri, 31 Dec 2004 05:00:35 GMT

Tammy wrote:

>
> Andrew McDonagh wrote:
>
>> It certainly prevents MOST bugs from happening - as the test code
>> (which is written first) must have a bug* which allows the application
>> codes bug to be undetected (i.e. not executed during a test run).
>
>
> Then how many bugs do you find?

It might be useful to categorize bugs, rather than
put them all into the same bucket, e.g.

Category 1: The system is unusable unless this bug is fixed.
(One presumes TDD adresses this problem quite well.
There may hav been bugs during development, but they
were cleared up before shipping to the client.)

Category 2: The system is broken, but can be used with
some bellyaching from the users. They are not happy.
(One presumes that TDD addresses this problem quite well
also.)

Category 3: The system does what it's supposed to do,
but certain things go haywire once in a while. (This
may or may not be a Cat 1 or 2 bug, depending on the kind
of system you're working on.)

Category 4: "Wouldn't it be nice if" (WIBNI) the system
also did *this*. This is not a bug but an enhancement
request. If it is of high value, you might work on it
prior to a Cat 3.

Notice, that I didn't mention anything which was caught
either by developer testing, integration testing, system
tesing or the like. Nor did I mention typo's pre-compile.

So, now, Tammy, what kind of bugs are you talking about?

A very strict definition of a bug is "one that is delivered
to the customer." I don't think you have that in mind, though.

NPL

Note: I am not an avid proponent of TDD. I feel that
it's just one tool in the craftsman's toolkit. Not the
end-all and be-all. But, it's useful for functional
requirements. It's use for performance and realiability
requirements is still suspect. 

-- 
"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?
    ... > anything would be different with TDD? ... Changing the code a lot, maybe while following a plan, denies tests during ... But suppose the 3rd ability introduced a bug, ... But TDD is not the same as developers writing tests after the features they ...
    (comp.object)
  • Re: OO in Python? ^^
    ... > That sentence is only true if your tests are bug-free. ... > because of a bug in the tests. ... let's be careful not to oversell or overhype TDD, ... the specs (generally underspecified specs); since the writer of the test ...
    (comp.lang.python)
  • Re: interpretive vs. compiled
    ... Hardly a reason to never do TDD, ... been written with that specific bug in mind). ... Sorry, this should not be a political forum, where people adjust their rhetoric based on which camp they suspect their adversary lives in. ... Some people use the word "refactoring" to mean they thumped on a design for a while, broke things, fixed them, and only then checked in. ...
    (comp.programming)
  • Re: Graphics programming recommendation
    ... TDD is a system to write a failing test case before writing code to pass the ... test, in tiny cycles, with frequent small refactors to improve design. ... Without the tests, when you discover a bug, you must debug it, because you ... advanced research environment. ...
    (comp.programming)
  • Re: TDD doesnt suck
    ... I erred on the side of TDD in my reporting ... After detecting the bug (by *inspection*, ... my ego into proving or disproving TDD. ...
    (comp.lang.c)