RE: [stellation-res] Unit test organization

["Jonathan Gossage" <jgossage@xxxxxxxx>]

> >-----Original Message-----
> >From: stellation-res-admin@xxxxxxxxxxxxxxx
> >[mailto:stellation-res-admin@xxxxxxxxxxxxxxx]On Behalf Of Mark C.
> >Chu-Carroll
> >Sent: January 11, 2003 1:30 PM
> >To: Stellation-res
> >Subject: RE: [stellation-res] Unit test organization
> >
> >
> >On Sat, 2003-01-11 at 13:20, Jonathan Gossage wrote:
> >> > >-----Original Message-----
> >> > >From: stellation-res-admin@xxxxxxxxxxxxxxx
> >> > >[mailto:stellation-res-admin@xxxxxxxxxxxxxxx]On Behalf Of Mark C.
> >> > >Chu-Carroll
> >> > >Sent: January 11, 2003 11:36 AM
> >> > >To: Stellation-res
> >> > >Subject: Re: [stellation-res] Unit test organization
> >> > >
> >> > >
> >> > >
> >> > >Big +1. This addresses several things that have been 
> >concerning me, in
> >> > >good fashion.
> >> > >
> >> > >First, the unit tests are getting confusing. As we add more tests,
> >> > >it's getting harder to find things in the unit test 
> >project, and hard
> >> > >to determine what is testing by what suite. Since I expect 
> >the number
> >> > >of unit tests to increase dramatically as we work through 
> >the upcoming
> >> > >release series, I think that's only going to get worse.
> >> > >
> >> > >Second, I think we have too many projects, which have 
> >dependencies that
> >> > >are tricky. Since we'll be switching to Stellation as our 
> >primary SCM
> >> > >system very soon, and we don't do subprojects yet, dealing 
> >with version
> >> > >consistency is going to become an issue. Keeping the tests 
> >in the same
> >> > >projects as the things they test allows us to eliminate one 
> >project, and
> >> > >to ensure that the tests and their subjects are always
> >> > >version-consistent.
> >> > >
> >> > >	-Mark
> >> > >
> >> 
> >> Have you considered the possibility of putting the entire 
> >Stellation system
> >> into a single Eclipse project. I find that the Eclipse concept 
> >of a project
> >> does not bring a lot except if you have peculiar resource or building
> >> requirements. Setting up the system for installation etc. is totally
> >> orthogonal to the Eclipse project organization.
> >
> >The main reason for treating things as separate Eclipse projects is
> >because as we migrate deeper into Eclipse, each of the projects is going
> >to become an Eclipse plugin. (Actually, they are separate plugins now,
> >but they're "shallow" plugins. But as we progress, they'll start using
> >much more of the plugin infrastructure.) 
> >
> >Eclipse does require that each plugin must be a separate project. And
> >there are important reasons for packaging Stellation as a set of plugins
> >rather than a single plugin: the command-line shouldn't depend on
> >Eclipse GUI components; if we package things together, there'll be no
> >way to run Stellation from the command line using the Eclipse launcher
> >without having it depend on the GUI components used by the Eclipse GUI
> >client. 
> >
> >	-Mark
> >
 I had forgotten about that one :-(

Jonathan