Re: [stellation-res] Unit test organization

["Mark C. Chu-Carroll" <mcc@xxxxxxxxxxxxxx>]

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

-- 
Mark Craig Chu-Carroll,  IBM T.J. Watson Research Center  
*** The Stellation project: Advanced SCM for Collaboration
***		http://www.eclipse.org/stellation
*** Work: mcc@xxxxxxxxxxxxxx/Home: markcc@xxxxxxxxxxx