"Craig R. McClanahan" wrote:
>
> On Thu, 15 Nov 2001, Paul Speed wrote:
>
> > Date: Thu, 15 Nov 2001 14:40:35 -0500
> > From: Paul Speed <[EMAIL PROTECTED]>
> > Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> > To: Tomcat Developers List <[EMAIL PROTECTED]>
> > Subject: Re: Distributed Session Management
> >
> > The only problem with including the tests right in the same package
> > is that they can be hard to remove for a test-free distribution. Also,
> > since they are in the same package, they have access to some non-public
> > methods and properties... this can make them a security risk in some
> > cases (especially since they can't be easily removed).
> >
> > When opting not to build a separate hierarchy for test classes, we
> > always created a "test" sub-package.
> >
> > I can present numerous reasons why it is better to use a separate
> > hierarchy, but I'm not sure I'd change anyone's mind. :)
>
> There's actually a solution that works for both camps: parallel source
> directory hierarchies.
>
> src/java/org/apache/foo <-- Contains the implementation
> src/test/org/apache/foo <-- Contains the tests
Right, that's my preferred approach as well. The other nice thing
about a separate source hierarchy is that if you decide to one day
change testing methodologies, your real source tree is still pure.
Just create a src/junit/org/apache/foo or src/supertest/org/apache/foo
as needed.
-Paul
>
> Then, just set up your build scripts to only compile the tests if you need
> them -- a build to create a distribution will omit them. Yet, the test
> classes will still be in the same Java package, so you can test package
> protected methods without having to modify the implementation classes.
>
> The existing JUnit tests in jakarta-tomcat-4.0 (plus bunches of other
> Jakarta projects like those in Commons) follow this style.
>
> > -Paul
> >
>
> Craig
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
