Colin Putney wrote:
> On 2010-01-25, at 1:39 PM, David T. Lewis wrote:
>
>   
>> I like Juan's idea a lot, but I lost some enthusiasm when I got to the
>> part about it being a lot of work ;-)
>>
>> Maybe by starting with the "quick-cheap" analysis that Nicolas suggests,
>> it might be manageable.
>>
>> I think that it would be important that the work be done in small chunks
>> that can be contributed easily. We need to consider who is doing the work,
>> and why they would be motivated to spend time on it. For example, the
>> OSProcess package that I maintain (and I don't know if this is a good
>> example) already has a large set of unit tests that fail right away if
>> an expected interface changes. I would be willing to put some work into
>> writing new tests that document just the api expectations alone, but I
>> would not want to sink a large amount of time into it because it's
>> likely to be boring work that does not provide much additional benefit
>> to me.
>>     
>
> I think you've hit the nail on the head here. Tests are indeed useful, but they work best when they test the functionality of interest. The base-level APIs are only interesting insofar as they affect the functionality that OSProcess provides. If you have a solid set of tests for OSProcess, and they all pass, who cares about the APIs?
>
> From a more practical perspective, writing tests for OSProcess directly is simply easier. You can pin down the functionality you're after. (If you can't, why the heck are you writing it?) The environment that OSProcess expects to run in is much harder to specify. Should you, say, test that Dictionary implements #at:put:? Or is that assumed to be so universal in a Smalltalk implementation that it's not worth testing? Trying to specify exactly what OSProcess expects from its environment is an exercise in frustration. The only way to do it is to do a port, and see what breaks. This is what the Grease developers have done, and even limited to things that have proven to be portability issues it's a big task. 
>
> In summary, I think a better approach is to write lots of good tests for your package, and rely on them to tell you if the environment isn't what is needed. 
>
> Colin

You're right, but there's Grease. If other packages besides Seaside 
adopt it, it is a win-win.

Cheers,
Juan Vuletich