Cool! This is just the sort of discussion I was fishing for. I love
collaborative development!
> > > > 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.
>
You're right - I didn't know that. Thanks for illuminating me. :-)
> 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.
On the surface this seems unorthodoxed, but I think it makes a lot of sense. And
unless someone gets really ambitious, it may be quite some time before very many
tests are written. Therefore, if down the road we find that it causes more
confusion than not, we can re-think this solution. Also, seeing the test cases
alongside the original classes might help us remember to create test cases for
new code. ;-)
How about the following?
- Specific test-cases should appear alongside the class to be tested.
- Test-cases should be named [ClassToBeTested]Test.java. This allows the
tests to be filtered-out by Ant during distribution builds.
- "Top-level" test harnesses (if any) should be rooted at
org.apache.turbine.tests.
Unless there are objections, I'll proceed along these lines. I'll also work on a
doc that explains the method to our madness.
> --
>
> Daniel Rall <[EMAIL PROTECTED]>
>
--
Christopher Elkins
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
