db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bernt M. Johnsen" <Bernt.John...@Sun.COM>
Subject Re: Testing & Classpath concern
Date Thu, 01 Jun 2006 17:14:28 GMT
I think this is definitely a path we should follow.
(... the pun is in the "ah" of the beholder..... ;-)
Especially the idea that each separate test/testsuite should have a
well defined and controlled environment it should run in.

>>>>>>>>>>>> Daniel John Debrunner wrote (2006-06-01 09:14:04):
> 
> 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.
> 
> 
> 
> 
> 

-- 
Bernt Marius Johnsen, Database Technology Group, 
Staff Engineer, Technical Lead Derby/Java DB
Sun Microsystems, Trondheim, Norway

Mime
View raw message