On 7-Jul-08, at 2:31 PM, nicolas cellier wrote:

> Colin, Igor,
> thank you, you have some good ideas.
> They do not match my requirement though.
> I don't want to test a specific implementation,
> I want to test a feature.
>
>    self should: [33 printStringBase: 1] raise: Error.
>
> The idea is to have some generic tests automated to check base  
> images and/or packages.
>
> Unfortunately, current implementation will not fail, it will loop!

I understand what you'd like to achieve. One of the most important  
design goals in test cases is clarity on what it means to pass the  
test and what it means to fail. Ideally, you want assertions you make  
about your code to correspond to your goals as a programmer as closely  
as possible. So yes, you'd like to write something like:

self denyLoopsInfinitely: [10 printStringBase: 1].

But that's impossible for the general case. So my suggestions were  
about finding a degenerate case that would at least make it possible  
to detect whether or not your fix has been applied. That would at  
least prevent regressions. That kind of test is ugly and brittle,  
though, and it might be better just of fix the infinite loop and move  
on.

Your idea of automated test suites that put limits on the resources  
that can be consumed during testing is interesting. I do think that  
Squeak should have some kind of automated nightly regression tests,  
and that might be something to implement there.

Colin