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
> Tom Drake wrote:
> >
> > Mika:
> >
> > ----- Original Message -----
> > From: "Mika Goeckel" <[EMAIL PROTECTED]>
> > To: "Tomcat Developers List" <[EMAIL PROTECTED]>; "Tom Drake"
> > <[EMAIL PROTECTED]>
> > Sent: Thursday, November 15, 2001 3:31 AM
> > Subject: Re: Distributed Session Management
> >
> > | Tom,
> > |
> > | from my (personal?!) philosophy, tests should be with the tested targets.
> > My
> > | experience tells me that tests get out of focus if they are in a separate
> > | tree.
> >
> > I agree, I like to place them in the same package as the code being tested.
> > In other projects, I've used a naming convention to distiguish between
> > Test classes and other classes (e.g. test classes are named Test?????.java)
> >
> > | Now when you are going to start hacking, is your approach creating use
> > | cases, sequence diagrams etc. before, or something like class
> > responsibility
> > | cards?
> >
> > Usually, I use a combination of things. In my mind the electronic equivalent
> > of class responsibility cards are java interface definitions or sparse
> > classes
> > with some javadoc. The initial message that I sent out that started this
> > thread
> > had a couple of java interfaces. I'll be sending some more around. I'll may
> > also
> > send some class diagrams, and sequence or collaboration diagrams.
> >
> > Tom
> >
> > P.S.
> >
> > |
> > | M.
> > |
> > | ----- Original Message -----
> > | From: "Tom Drake" <[EMAIL PROTECTED]>
> > | To: "Tomcat Dev List" <[EMAIL PROTECTED]>
> > | Sent: Wednesday, November 14, 2001 8:39 PM
> > | Subject: Distributed Session Management
> > |
> > |
> > | > Tomcat Developers:
> > | >
> > | > I'm going to try to synthesize the results of yesterdays
> > | > discussion on Distributed Session Management into some
> > | > working code. From what I can tell, there will be some
> > | > changes and new objects in the org.apache.session
> > | > package, and possibly some new objects in the
> > | > org.apache.cluster package.
> > | >
> > | > I should have something to share in the next couple of
> > | > days. I'll be creating JUnit tests as I write this code. Is there
> > | > a standard place to put JUnit tests, or can I simply place
> > | > them in the same package as the classes being tested?
> > | >
> > | > Regards,
> > | >
> > | > Tom Drake
> > | > Email: [EMAIL PROTECTED]
> > | >
> > | >
> > | > --
> > | > To unsubscribe, e-mail:
> > | <mailto:[EMAIL PROTECTED]>
> > | > For additional commands, e-mail:
> > | <mailto:[EMAIL PROTECTED]>
> > | >
> > |
> > |
> > | --
> > | To unsubscribe, e-mail:
> > <mailto:[EMAIL PROTECTED]>
> > | For additional commands, e-mail:
> > <mailto:[EMAIL PROTECTED]>
> > |
> > |
> > |
> >
> > --
> > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
