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 11:33 AM
> >To: Stellation-res
> >Subject: Re: [stellation-res] Unit test organization
> >
> >
> >On Sat, 2003-01-11 at 11:19, Jeffrey Howard wrote:
> >> Hello,
> >>
> >> > Eclipse provides good support for this metaphor since it
> >permits multiple
> >> > source tree  within a single project. So all we need to do
> >is to create a
> >> > parallel structure to the "src" rooted structure that
> >currently exists that
> >> > will hold the additional low level unit tests. We use this
> >principle with
> >> > great success in my organization whre we name the parallel
> >tree "test".
> >> >
> >> > Any thoughts on this?
> >>
> >> There is another way of organizing tests that we use here at work.  It
> >> takes advantage of the fact that inner classes can still extend other
> >> classes.  The setup looks like:
> >>
> >> class MyClass {
> >> 	private Object privateData;
> >> 	Object packageData;
> >> 	public Object publicData;
> >>
> >> 	private Object privateMethod() {
> >> 		...
> >> 	}
> >>
> >> 	Object packageMethod() {
> >> 		...
> >> 	}
> >>
> >> 	public Object publicMethod() {
> >> 		...
> >> 	}
> >>
> >> 	public static class TestMyClass extends TestCase {
> >> 		... [Lots of JUnit tests]...
> >> 	}
> >> }
> >>
> >> The advantage of doing it this way is that TestMyClass gets access to
> >> everything inside the class that it's testing, including private data
> >> and methods such as privateData and privateMethod in the example
> >> above.  Since we do a fair amount of white box testing as part of our
> >> unit testing, the added visibility to the test class is often quite
> >> helpful.  It saves us a lot of effort in reconstructing what the
> >> internal state of the object must be from external behavior.  Another
> >> advantage is that it's very easy on the build system, because the tool
> >> set doesn't need to be able to handle multiple source trees.  Though
> >> as you pointed out, this isn't really a problem if you're developing
> >> under Eclipse.  When building up the test suite, you just use a call
> >> of the form:
> >>
> >> ts.addTestSuite( MyClass.TestMyClass.class );
> >>
> >> Eclipse hasn't had any trouble automatically detecting these when
> >> doing a Run as JUnit command.
> >>
> >> The corresponding disadvantage is that it's no longer possible to ship
> >> a release without having the unit tests go with it.  Personally,
> >> that's never bothered me.  I suppose if you're distributing by
> >> download over very slow links, it could become a problem.
> >>
> >> Stylistically, some people like the fact that the class and the tests
> >> for it are all rolled up into one file.  Some people find that having
> >> the unit tests appended to the source file makes the source file seem
> >> cluttered.  I like having everything together in one place.  Eclipse's
> >> JDT makes it easy enough to navigate source files that I don't find
> >> that it impedes my ability to work with the code.  That seems to be
> >> mostly a matter of personal preference, though.
> >>
> >
> >I think in Stellation it's going to get very cluttered. Stellation's
> >design winds up with certain "bottleneck" classes that have a lot
> >of functionality, and that are going to have multiple test suites that
> >probe different areas of their functionality.
> >
> >I prefer Jonathan's suggestion, which lets us keep the tests in
> >one easy to find place, distinct from the basic implementation code. The
> >browsing cost of this is pretty minimal, especially with the
> >hyperlink-like capabilities in the recent Eclipse milestones. (Hold
> >the control key, and put the mouse over a name. If it underlines, then
> >clicking on that name will pop the editor to the thing you clicked.
> >There's also a "back" button on the toolbar (with corresponding keyboard
> >shortcut) to go back. So I'd suggest following Jonathan's plan, and
> >adding to the coding guidelines that in the Javadoc for each
> >class, we put an "@see" link to the tests for that class.
> >
> >	-Mark
> >
I must admit that I have yet to find a need for direct private access to
methods or variables, finding that I can do everything throughpublic or
package visibility methods. I do find that I use package visibility a lot to
reduce the visibility of methods, particularly in package implementation
classes which often wind up not needing any public members at all except for
methods that implement interface methods.

Regards

Jonathan

Personal email
jgossage@xxxxxxxx

Business email
jonathan@xxxxxxxxxxxxxx