db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Testing & Classpath concern
Date Thu, 01 Jun 2006 16:14:04 GMT

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?


View raw message