Forgot to point you to some mail concerning the previous state of the  
art....

http://lists.squeakfoundation.org/pipermail/squeak-dev/2003-September/ 
066288.html

On Dec 13, 2004, at 13:03, Hannes Hirzel wrote:

>
> Markus Gaelli wrote:
>> 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?
>
> Yes, today for example this would be
>
> ftp://st.cs.uiuc.edu/pub/Smalltalk/Squeak/3.8beta/Squeak3.8g-6527.zip
>
> and
>
> ftp://st.cs.uiuc.edu/pub/Smalltalk/Squeak/3.9alpha/Squeak3.9a-6532.zip
>
>
>
>> 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 see. So where is the server and the last emails which were sent out?
>
>
>>> I do not see the fingerprint thing to be an issue.
>>
>
>> 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?
>
> I see, you are looking for some heuristics to find out which unary  
> methods might be candidates as test cases.
>
> An related idea to this is to look for unary method calls and  
> autogenerate test cases for the classes they belong to.
>
> For the test cases there might be an interface / query tool for  
> selecting them easily and moving them to the actual test case pool.
>
> However the first step I perceive the very crude test
>
> load a packacke
> 	succeeds
>         fails
>
> already giving 50% of the success of automatic testing.
>
> Or even more basic just to try get working again with the most recent  
> images what Daniel had working.
>
> Or if you do not have time at least document it enough so that somebody
> other in the list might have enough knowledge to help out.
>
>
> Hannes
>
>