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

David T. Lewis lewis at mail.msen.com
Mon Dec 9 13:08:45 UTC 2013


On Mon, Dec 09, 2013 at 08:25:39AM +0000, Frank Shearar wrote:
> On 09 Dec 2013, at 7:07, Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com> wrote:
> 
> > Yes, separating tests is a good practice and already almost universal practice in current Squeak, as well as in many 3rd party packages.
> > 
> > If you don't want to create a specific package, then there is a blob named 'Tests' already, but I'd rather see this blob split into pieces. The reason is that if you want to test an image constructed from parts, you might want to test those parts exclusively.
> > 
> > 
> > 2013/12/9 Chris Muller <asqueaker at gmail.com>
> > There has been a great effort headed up by Frank to organize behaviors
> > into a hierarchy of packages with no cyclic dependencies.  This is a
> > great goal and great effort.
> > 
> > But the introduction of this new package (with just two classes)
> > prompts a need to understand what _all_ the goals are for this
> > process.  Certainly, everyone agrees we want no cyclic dependencies
> > between packages.
> > 
> > But this extraction doesn't help that.  Nothing will ever depend on
> > ToolBuilderTests, so how does this new leaf of the package-dependency
> > hierarchy, justify its existence in cyberspace?
> 
> ToolBuilder no longer depends on SUnit. I fail to see how that's bad.
> 
> > Getting SUnit completely out of the image will mean ALL packages must
> > be split between their "-Kernel" and "-Tests" components.  Is that the
> > plan?
> 
> I suppose eventually, yes. What's the point of unloading ST80 but leaving its tests in Tests?

I do not understand your example. Which tests are you referring to?
I don't see any ST80 tests in the Tests category.

I'm just asking for clarification.

Dave



More information about the Squeak-dev mailing list