[EMAIL PROTECTED] wrote:
(Personally I'm less sure that it that important to map the various classifications onto the package/directory structure. I would prefer a simpler/flatter package structure that could accomodate a variety of tests without modification to the structure. Grouping/classification could be done using Junit features (suites and labeling). But as usual; I seem to be the only one that thinks so... :)
Well, today's situation may suggest that if we were to start over from scratch, your suggested approach may actually be the way to do it.
Now that we already have the "functionTests", "unitTests", "system" and "perf" packages things get more complicated - though it's probably not impossible to change it if we wanted to...
I'm not really sure how we define the term "function test" in in this project. One could say that unit tests are also function tests, and put them all (at least the new (JUnit) ones) in the functionTests package - and live with the slightly confusing fact that there is also a separate "unitTests" package for the older tests.
If we need a separate sub-package for unit tests only (under functionTests), it is perhaps good enough to share the .unit package with the "old" property files that are already there? Or move the property files to a "legacyTests" sub-package or something?
(By the way, the testing-readme describes the old unit tests as tests that "test more underlying functionality than the (rest of the) functionTests, which are more geared toward how end-users might use functionality." This suggests that the old unit tests were/are considered function tests as well.)
Having said that, I'm also OK with e.g. creating a new derbyTesting.unitTests.junit package and put new unit tests there.
My guess, based on the comments so far, is that the option you (or someone else) decide to implement will be accepted :)
-- John
