Test classes ( was: Re: MC in basic)

Romain Robbes romain.robbes at lu.unisi.ch
Wed Dec 15 11:04:43 UTC 2004


On Dec 14, 2004, at 8:25 PM, Tim Rowledge wrote:

> Hannes Hirzel <hirzel at spw.unizh.ch> wrote:
>
>> If you argue that test classes add to the real complexity I cannot but
>> wonder. The only thing they do is to make inherent complexity 
>> explicit.
> One small but irritating factor of the tests is that there seem to be a
> gazillion class categories of them. They're not terribly regularly
> named. They're all over the category list in the browser.
>
> I posit that simply putting them all into a single category would hide
> them well enough to make things a tad less confusing. Normally I'd
> prefer a sensible breakdown into multiple categories of course, but
> they're just peripheral classes and mostly used by the testrunner so
> what the hell.
>

But if you want to package them with Monticello, they have to be in the 
same category ...

This looks like the more general problem of whether you want to see all 
the system in
the class browser. Omnibrowser can for example browse a single package 
at a time
IIRC. What would be nice for most of the time is I think to have a 
browser which
displays several packages, which constitute your "working set", and 
have all
operations such as senders, etc ... work on this set (which could be for
example Kernel, Collections, and the app you are working on).
Then tests should be hidden as well and only shown when they make sense
as Markus and I are trying to do with BrowseUnit, and his extension to
Omnibrowser.

I think that if such a browser would exist, it would ease system 
exploration a lot ...
we could have a browser for "newbies" (I mean still interested in 
smalltalk programming),
containing packages Kernel, Collection, Tutorials ...
And maybe some other browsers like "browser to learn morphic", allowing
a smoother learning curve ...

I think this is really doable. I have some code lying around, 
subclassing SystemNavigation
to work on part of the system. I use it in my services-base package, to 
have senders and implementors
on various parts of the image (package, category, image, and class 
hierarchy).

I think that Omnibrowser uses a quite similar mechanism by the way.

Cheers,
	Romain

>
> tim
> --
> Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
> We can rescue a hostage or bankrupt a system. Now, what would you like
> us to do?
>




More information about the Squeak-dev mailing list