+1, I think this is a great point. The trick is achieving this :)
David Daniel John Debrunner wrote:
A couple of days ago I downloaded the 10.2 snapshot onto a new machine and set it up to run derbyall. I hit about 16 failures, some due to DERBY-1362 and some due to classpath issues. Thinking about this I'm becoming somewhat concerned that the derbyall & testing setup is forcing us to use a classpath setting that does not reflect a typical user classpath, that is the classpath needs to have every jar in it. This can lead to hidden dependencies, e.g. the embedded engine derby.jar depends on classes in derbyclient.jar. One of my beliefs is that the testing environment must match the user environments. Testing in any other way means that it is somewhat likely that a user finds a bug that should have been caught by functional testing. Thinking about it briefly, it seems there is a limited number of recommended classpaths for Derby, actually seven, which are (in terms of jar names): 1) derbyrun,jar 2) derbyclient.jar 3) derby.jar 4) derbynet.jar 5) derbyclient.jar + derbytools.jar 6) derby.jar + derbytools.jar 7) derbynet.jar + derbytools.jar [There are probably others, but these are the main ones] Could we have it set up so that each test selected its own classpath, maybe based upon test type, or "logically" based upon a naming scheme that allows future changes without modifying every test? Could this be done in the Junit world? I believe then we would have a higher confidence level that an embedded .java test is not requiring classes from derbynet.jar or derbytools.jar? Thoughts? Dan.
