gnu-arch-users
[Top][All Lists]
Advanced

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

Re: [Gnu-arch-users] more on the merge-fest


From: Andrew Suffield
Subject: Re: [Gnu-arch-users] more on the merge-fest
Date: Wed, 26 Nov 2003 02:09:08 +0000
User-agent: Mutt/1.5.4i

On Tue, Nov 25, 2003 at 12:59:48PM -0800, Tom Lord wrote:
> Sorry to reply to myself but:
> 
>     > From: Tom Lord <address@hidden>
> 
>     > There's nothing special about tests that makes them any less
>     > susceptible to bugs than anything else.   It's just the separation of
>     > effort to produce redundant expressions that you expect to agree that
>     > counts.  
> 
> In the extreme: screw sticking to just tests -- separately write the
> program multiple times and run them in parallel.  I've heard that this
> is an approach frequently used in spacecraft and other rockets -- and
> those things hardly _ever_ fail :-)

Experimentation has led me to settle on something not overly distant
in effect. My test suites usually take the form of a minimal
reimplementation in a different language - if I'm writing C code, I'll
do the test suite in perl (these two fit together well). The bulk of
the test suite consists of a set of input data, and an implementation
which is "just correct enough" to generate the right output for that
input (no error handling).

The idea is that the languages and techniques used will be so
radically different that the chances of both having the _same_ bug
will be minute - it doesn't really matter if the test suite has bugs,
because they're detected just as readily as bugs in the application
being tested. All that matters is that they must be different bugs.

I've found this to be quick to develop and an effective first line of
defence against bugs and unexpected shifts in behaviour.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'                          |
   `-             -><-          |

Attachment: signature.asc
Description: Digital signature


reply via email to

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