[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
|