[Q] A new attempt to create a Squeak Test Server +Image Fingerprints

Thomas Koenig tomkoenig at mindspring.com
Mon Dec 13 23:06:41 UTC 2004


Markus,
Is there some way I could help you with this effort?  I've some
experience with writing sunit tests.
If we are going to change rapidly (which we must) and reliably (which we
must) then we need ideas like the one you are proposing.  I don't want
to choose between a radically improved infrastructure and a trustworthy
face to the world.
Tom

> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org 
> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On 
> Behalf Of Markus Gaelli
> Sent: Monday, December 13, 2004 5:28 AM
> To: The general-purpose Squeak developers list
> Cc: Daniel Vainsencher
> Subject: Re: [Q] A new attempt to create a Squeak Test Server 
> +Image Fingerprints
> 
> 
> Hannes,
> 
> thanks for your motivating words.
> 
> > For the beginning even a relatively modest thing would be 
> tremendously
> > helpful.
> >
> >
> > ---------------------------------------------------------------
> > The use case:
> >
> > a) take a base image (3.8g for example)
> > b) follow a loading list (e.g. the packages for full)
> > c) load a package and create an entry in a log text file
> > d) do this until all packages are successfully loaded.
> > e) send an email with the following notes to this list
> >    (weekly)
> >    the version of the base image, the packages loaded.
> >
> I think you identified a very important use case.
> I assume that you mean the newest versions of this packages 
> available, 
> no?
> So this would make sense on a moving target, meaning to try 
> to load the 
> newest versions into the _actual_ image version, right?
> >    -----------------------------------------------------
> > Result:
> > The sucess of the test is indicated by a email
> >
> > Error:
> > The process of loading may stuck. A crude and easy way to 
> detect this 
> > is just a time out superwised by the calling shell script.
> >
> > The log file gives the last known package which loaded.
> > An error report describing this is sent to the list as well.
> > ---------------------------------------------------------------
> >
> >
> >
> >
> > As a package loading list we could start with 'Full'
> > and later add variants of it.
> >
> >
> > Later one (when SM has dependencies) your test robot could go to
> > SqueakMap and load all the packages listed there as 
> compatible with a 
> > certain version. Developers could even check a box that they are 
> > informed automatically if their package does not load.
> >
> > But for the moment we should limit ourselves to hand crafted package
> > loading list.
> >
> > If you manage to set up this Test Server again that would be a
> > tremendous contribution for the community. Notably one that 
> safes each 
> > one on the list a lot of trouble ....
> Big thanks goes to Daniel Vainsencher, who installed it, and 
> made work 
> the first time! But somehow university got both of us distracted 
> again...
> >
> >
> >
> > I do not see the fingerprint thing to be an issue. Just take the
> > images from the download directory. They are tagged with the change 
> > set version number. For the beginning that is fine.
> I did not explain it very well, I guess. The idea is to 
> harvest all the 
> unary methods (at least the ones on the class sides) and use them as 
> "smoke tests".
> Some of them might never run, but if some ran in an earlier 
> version and 
> now not anymore, that might mean sth.
> 
> In order to get them I was thinking to use this fingerprint approach, 
> as you want to make sure, that no side-effects of some earlier tests 
> occur.
> For academic reasons I would be quite interested in this 
> approach: has 
> this been done before, is it useful, is it feasible?
> >
> > Thank you again for this initivative.
> >
> Thanks again for clarifying this useful use case and cheering 
> words :-)
> 
> Markus
> 
> 




More information about the Squeak-dev mailing list