[squeak-dev] modularity goals (was: The Trunk: ToolBuilderTests-fbs.1.mcz)

Chris Muller asqueaker at gmail.com
Mon Dec 9 23:37:09 UTC 2013


I want you to know, several of my packages like Ma-Serialization and
Magma DO separate out a "-Tests" package from the core functionality
-- because they're biggish.  For me, it was only when the tests were
so minor in size that I decided I didn't warrant the extra "line item"
in the package list, file-directories, etc.

> I do appreciate your point that an excessive number of fine-grained
> packages would be daunting to manage. I try not to create new
> packages. In this case, it seemed like the natural thing to do.

I _am_ glad for what you said above.  We definitely agree it's a
natural thing to do, if not always the threshold of when we should do
it.  Not a big deal for "-Tests" packages.

>> So one can run its tests and know that the GUI-specification is
>> performing correctly, of course!  :)  Before deploying an image to
>> production is a good time to run tests.
>
> :) But of course you don't mean that the _specs_themselves_ should
> depend on TestCase. But if you bundle the thing-under-test together
> with the tests, you can't separate the two.

This is why I said earlier that stripping was not being given due consideration.

Shrinking/stripping activities are already a regular part of
Configuration-for-deployment.

Much less so for configuring a development image.  That's the time
when I "want everything" and as few complications as possible to get
there.

I can relent for this "-Tests" idiom but, mark my words Frank, I'm
watching you!  :)  If tiny new packages besides "-Tests" start
appearing, we'll be having this conversation again.

PS -- Since it was for aesthetic reasons, it would be better and more
consistent if it were named "ToolBuilder-Tests" instead of
"ToolBuilderTests".


More information about the Squeak-dev mailing list