[Nitro] self-test

[* William]

Good morning/ Good evening/ Good night.

Comments in-line.

-----Original Message-----
From: Jonathan Buch [mailto:john at oxyliquit.de] 
Sent: Wednesday, 25 July 2007 18:19


w>  I have a comment on these recurrent "test" errors and "regression" 
w>  ...
w>      DRY

j>  I really like your idea, but there is a _big_ hinderance for me 
j>  there.  :) Time.  Even the current startup is sub-optimal, 
j>  with tests there'd have to be a 'do test' switch which enables 
j>  testing for those who do want to run those.

Yes -- I appreciate this.  

The suggestion is more of a "challenge" to find an solution that is:

  -- Optimal
  -- Effective, and
  -- Efficient

On real operating systems (and probably Windows now) one might fork() a
self-test routine in parallel.  That would not impact the mainline
execution. ;-)

I am I saying that's a solution?  Not really.  I want to illustrate that
there 
Are ways to make it happen, by being ambitions.

j>  Nitro/Og tests take around 15 minutes for me to run, 
j>  I'd be crazy to enable this.

Yes, that too.  Why not consider some old-fashioned technology.  

When teletypes were unreliable, we needed to check the data.  

Here's an option.

j>  IMO there isn't so much duplication going on in the 
j>  tests as simply 'usage' of facilities (at least in Og).  

While that may or may not be the case -- Industry ready code finds
regression error all the time until someone takes action to stop it.

A simple idea is to "check" the code when it is patched.

I see an example from darcs in another post.

I was also wondering if a "check-sum" might be used to identify changed
classes, etc.  

So far a simple expression of the notion has defeated me.  ;)

As I say a challenge for the masses ::: Set forth (oops Ruby) and multiply.

/... Will.

No virus found in this outgoing message.
Checked by AVG Free Edition. 
Version: 7.5.476 / Virus Database: 269.10.16/914 - Release Date: 23-Jul-2007
19:45