----- Original Message ----- From: "Craig R. McClanahan" <[EMAIL PROTECTED]> To: "Tomcat Developers List" <[EMAIL PROTECTED]> Sent: Thursday, November 15, 2001 11:39 AM Subject: Re: Distributed Session Management
| | | 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 | | 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 | Thanks Craig. That's what I was looking for. I didn't want to invent anything new in this regard. Tom -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
