I apologize in advance for going off again. (See my earlier response to 
the call for info/best-practices.) But I can't help but think about 
"those who fail to learn from history..."  Here we are with all these 
wonderful and practical ideas about doing just "one more thing" to make 
stuff really work, and I'm unhelpfully being abstract. Sorry. And I 
don't mean to discourage anyone. Just giving a heads-up.

What's fundamentally at issue with tests and with packages? At their 
core, these are both declarative-style collections of things to be 
operated on. The "win" is that the user doesn't need to manually carry 
out the operations, and that the system can manage the combination of 
collections and operations. (E.g., interleave complex combinations.)

The key point I'm trying to make is to recognize that we're dealing with 
collections of stuff that can be combined, and with operations that can 
be combined. As I understand them, SUNIT and MC don't really handle 
combinations of collections, nor do they interact with each other for 
combinations of operations. (Monticello configurations are a step in 
this direction, and before/after scripts in MC can be used to 
procedurally achieve some manual combination of operations, but then 
you're losing the power of the declarative definitions.)

So my feeling is that the various improvements to MC and SUNIT are just 
messing with the margins. Half a loaf. [This community will quite 
rightly shout, "Go ahead and do it!" I'll answer in advance that I'm 
working on other issues. This isn't on my critical path. Besides, my 
meta-point is that this whole area is an already-solved problem. If I 
had a student to throw at this...]

-H

[Another possible objection to the idea of combination is that what Lisp 
did sounds like Mark Twain's comments on smoking. "It's easy to quit 
smoking. I've done it hundreds of times!" The fact that this problem has 
"been solved" so many times might mean that it hasn't. My personal view 
is that it HAS been solved, but that there are other (social) issues 
that have caused it to be repeatedly solved in the Lisp community.]

Lex Spoon wrote:
> "Ralph Johnson" <johnson at cs.uiuc.edu> writes:
>> Squeak comes with a large set of SUnit tests.  Unfortunately, some of
>> them don't work.  As far as I can tell, there is NO recent version of
>> Squak in which all the tests work.
> 
> Known-failing tests should be marked in some way or another.  Thus far
> people have proposed putting them in separate packages so that you can
> simply unload them.
> 
> That is not a bad solution.  However, it would be better if you can
> load a known-failing test without having the tools bother you.  Then
> you can see the tests and mess with them.  To achieve this, however,
> you need to have a way to mark this in the image.
> 
> The simplest way I can think of is to rename the methods for
> known-failing tests.  Right now, a method named testFoo is a unit
> test.  We could change that so that pendtestFoo is a pending unit test
> that is known not to work.
> 
> 
> -Lex
> 
> 
> 
> 

-- 
Howard Stearns
University of Wisconsin - Madison
Division of Information Technology
mailto:hstearns at wisc.edu
jabber:hstearns at wiscchat.wisc.edu
voice:+1-608-262-3724