[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnu-arch-users] Re: Testing approach

From: Stephen J. Turnbull
Subject: [Gnu-arch-users] Re: Testing approach
Date: Sat, 29 Nov 2003 11:30:33 +0900
User-agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.5 (celeriac, linux)

>>>>> "Misha" == Misha Dorman <address@hidden> writes:

    Misha> Samuel wrote:

    >> On Wednesday 26 November 2003 03:21 am, Andrew Suffield wrote:

    >> > So, now you know that somewhere in that 500 line chunk lies a
    >> > bug. Are you seriously suggesting that you can often spot it
    >> > by inspection?

    >> Not only am I suggesting it, I've done it ... hundreds of
    >> times.

    Misha> With only enough info to narrow it down to 500 lines? I'm
    Misha> surprised.

That depends on exactly what you mean by 500 lines.  Typically in that
500 line _contiguous_ chunk there are half a dozen 10-line chunks, all
similar in form, that you really need to look at.

As usual in this kind of thread, people are talking past each other.
I'm surprised you're doing it here, because most of the rest of what
you said makes an awful lot of sense.  Especially as a corrective to
Samuel's naivete.  :-)

    Misha> Not because it isn't possible -- I've done it myself
    Misha> (probably tens or hundreds of times, though that is over
    Misha> the last ~15 years) and usually on code written by other
    Misha> people -- but rather because I got the impression that your
    Misha> tests would be granular enough to narrow it down more than
    Misha> that. Typically, I would expect testing/DbC granularity
    Misha> sufficient to narrow bugs down to 20-50 lines or so at most
    Misha> (approximately, a method).

Samuel made that point already, actually.

    Misha> Just because you _can_ find bugs by inspection in 500-line
    Misha> stretches of code -- and perhaps even enjoy the challenge
    Misha> -- doesn't mean it is a good idea :-)

That's really Samuel's point.  Andrew says he does most of his
debugging in gdb.  To me, that suggests (1) his implementations are
extraordinarily accurate realizations of the design, or (2) he
programs mostly in a special domain (such as device drivers for new
and poorly specified hardware) where testing is hard to do accurately,
or (3) he does way too little testing.  I think (3) is most likely,
and that's really Samuel's point.

And of course sometimes inspection is a good idea simply because it's
really the _only_ idea.

Institute of Policy and Planning Sciences
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]