[pedantic] Re: Tests and software process
Howard Stearns
hstearns at wisc.edu
Thu Nov 2 19:37:04 UTC 2006
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
More information about the Squeak-dev
mailing list
|