Christopher Elkins wrote:
>
> > Christopher Elkins wrote:
> > >
> > > Hi, all.
> > >
> > > While implementing OR query support in Criteria, I'm planning to create the
> > > beginnings of a JUnit test-case for it. What are people's opinions on the
> > > location of the test classes? I see at least two options:
> > > (1) src/java/org/apache/turbine/tests
> > > (2) src/tests
> > >
> > > Feel free to suggest other locations and/or naming conventions.
> > >
> > > Additionally, I see at least two options for organizing the test classes
> within
> > > the test root directory:
> > > (1) place all classes in one directory (which seems like a bad idea)
> > > (2) mirror the directory heirarchy of the main source code - for
> example,
> > > the CriteriaTest class would be located in [test_root]/util/db
> > >
> > > Thoughts?
> >
> > FYI, if you do it either of these ways, you can't easily test protected
> > or private methods.
>
> True. However, (to state the obvious) the only way we could _ever_ test private
> methods is by embedding the test code in the class to be tested; to test
> protected methods, the test class would have to extend the class to be tested.
> Another disadvantage of the two options above is that we wouldn't be able to
> test package-private classes.
Your reference to protected methods is incorrect, Chris. Protected
members have package level accessibility, meaning any other class in the
same package has access to them. This is a common misconception.
The package private classes are another good point (which I neglected to
mention). I know that this option may sound a bit distasteful, but we
could test a lot more thoroughly if we scattered the JUnit test cases
throughout the Turbine package tree, and kept only the test suites and
base tests in the org.apache.turbine.test package. I know that this may
sound weird at first, but tests are really a core part of the code.
Turbine is so big now that it's really hard to tell if everything is
working--hell, I don't know even what everything *is*, let alone how
it's supposed to work. Test cases really help solve this problem, and
therefore are really core functionality. This gives them the right to
live in the core source tree, and alleviates the headache of maintaining
a duplicate package heirarchy under the test package.
> I guess it boils down to whether the unit-tests should emphasize white-box or
> black-box testing. The options I outlined above implicitly assume that black-box
> testing has priority.
Black-box testing is preferable because it means less code to write. ;)
The downside of it is that often you can't get the granularity of test
cases that might otherwise be desirable.
--
Daniel Rall <[EMAIL PROTECTED]>
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
