db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Van Couvering <David.Vancouver...@Sun.COM>
Subject Re: Testing & Classpath concern
Date Thu, 01 Jun 2006 18:24:53 GMT
+1, I think this is a great point.  The trick is achieving this :)


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.

View raw message