Re: how many bugs do you find and correct during TDD?
From: Ilja Preuß (it_at_iljapreuss.de)
Date: 01/02/05
- Next message: Ilja Preuß: "Re: how many bugs do you find and correct during TDD?"
- Previous message: Mark Jeffcoat: "Re: how many bugs do you find and correct during TDD?"
- In reply to: Tammy: "Re: how many bugs do you find and correct during TDD?"
- Next in thread: Tammy: "Re: how many bugs do you find and correct during TDD?"
- Reply: Tammy: "Re: how many bugs do you find and correct during TDD?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sun, 2 Jan 2005 11:07:37 +0100
Tammy wrote:
> Ilja Preuß wrote:
>> Example: Does the for loop need to end at i<n or i<=n? Without the
>> tests, I'd think hard until I knew, possibly even execute the
>> algorithm manually on paper to be sure.
>
> Wow, i wonder if people take not knowing to this level?
> It seems to me you aren't able to keep those
> items in your mind at the same time and reason through the
> scenario correctly. Is that true? Or is it not worth the
> effort in your mind?
It's simply not worth the effort to me. I'd need to write and execute the
test anyway. Letting that test tell me is more effective to me than
reasoning about it.
Perhaps it's just me, but one-off index errors aren't that seldom to me,
even if I take my time to reason about it. The only way for me to know that
I got it right is to run the test.
> Where do you stop? Do you just put in any variable names
> and then correct them as it doesn't work?
No.
> Do you use any
> looping construct and then correct it until it works?
I don't understand what you mean.
> Do you use any comparison and then correct it until it works?
No.
> I really don't see the need to execute something on paper
> when you can execute it in your mind much faster with
> equal precision.
As I said, I find that I often get this special case wrong, no matter how
much I think about it.
>> With TDD, I just choose the one that looks more persuasive
>> and let the tests tell me wether it was the right one.
>
> How could you write a correct test if you can't reason what
> the post condition should be?
Let's take an algorithm that replaces two '$' by a single one:
assertEquals("a$b$c", foo("a$$b$$c"));
There possibly is a loop somewhere in foo. If there is, and it has a one-off
error, one of the following test cases could fail:
assertEquals("a$$c", foo("a$$$$c"));
assertEquals("$b", foo("$$b"));
assertEquals("a$", foo("a$$"));
assertEquals("", foo(""));
Writing these testcases, to me, is often much easier than reasoning about
wether the algorithm would make them pass or fail.
>> Would that count as finding a bug, by your definition?
>
> No. You don't expect it to work.
Yes, but I also don't necessarily expect it not to work... ;)
>> Well, it's probably more important to the customer, at least... ;)
>
> It is important. It's not the only thing that is important.
Do you think it is/should be important *to the customer* how many bugs we
find in the TDD cycle?
Cheers, Ilja
- Next message: Ilja Preuß: "Re: how many bugs do you find and correct during TDD?"
- Previous message: Mark Jeffcoat: "Re: how many bugs do you find and correct during TDD?"
- In reply to: Tammy: "Re: how many bugs do you find and correct during TDD?"
- Next in thread: Tammy: "Re: how many bugs do you find and correct during TDD?"
- Reply: Tammy: "Re: how many bugs do you find and correct during TDD?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
