If the test uses only the public api then it would make sense to keep the test separate from the module, eg a jini platform compliance test, or in this case a javaspace performance test, perhaps maintained in its own module with other javaspace tests, it should be external to the outrigger module, so it can be tested against both implementations.
Unit tests or performance tests that are implementation specific should remain with the module. We have a number of tests that test either the platform or the service for compliance. This includes the join and discovery compliance tests that are currently unmaintained. These should be mainained separately from other modules. So to sum up, you'd first develop a performance test using the qa harness module as a lib dependency, this performance test could be bundled with other performance tests for javaspace, these would be run without recompillation, against the new module implementation. The mechanics of implemeting that have not been done, so this is hypothetical. I wonder what thoughts others might have about how it might be implemented / structured? Peter. > > The issue I'm trying to understand is not the release of production > code, but the issue of how to organize benchmarks that need to be run in > order to decide whether to make a change. Depending on the benchmark > result, the change may not happen at all. > > Patricia
