db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Korneliussen <Andreas.Kornelius...@Sun.COM>
Subject testScript.xml and DerbyJUnitTest refactoring
Date Wed, 08 Feb 2006 10:33:59 GMT
I have considered refactoring DerbyJUnitTest because of the following:

The way DerbyJUnitTest supports configuring the testcase may be error 
phrone, since it requires the calling of a number of static methods in a 
  specific order for the static members to initialize.  I.e it is not 
possible to run any of the exisiting JUnit tests using a standard Junit 
  testrunner without getting a NullPointerException. The static members 
are also non-final, and this allows testcases to call modifiers, 
potentially causing side-effects in other testcase objects.

Example:DerbyJUnitTest has a public static method called 
setDatabaseName(String dbName). If I do not call it, the _databaseName 
variable is null.  If one of my testcases call the setDatabaseName(..) 
method, it has side-effects which will affect all other testcases (they 
may start using another database).

The way DerbyJUnitTest supports configuring the correct JDBC client, is 
by having a String[] of client settings for a framework. This can be 
initialized by calling setClient(..) or findClientFromProperties()

         private static String[] _defaultClientSettings;

	public	static	void		setClient( String[] client ) { 
_defaultClientSettings = client; }

	public	boolean	usingDB2Client() { return ( _defaultClientSettings == 
	public	static	final	String[][]	LEGAL_CLIENTS =

The problem with this approach is that:
1. I may call setClient(..) with any array of strings not being part of 
LEGAL_CLIENTS. This will cause the methods usingDB2Client(), 
using...Client() to all return false, even if my String[] array contains 
a valid set of strings for JDBC client settings.

2. Calling setClient(..) has side-effects on other testcases, and it 
allows "non-standard" initialization of the client settings

3. If I do not call setClient(..) or findClientFromProperties().. 
methods like getConnection() fails with NullPointerException

4. The problem of configuring the client settings has been solved 
before, i.e in TestUtil, where there is a integer enum representing the 

One thing preventing me from refactoring DerbyJUnitTest is that I 
noticed the testScript.xml in CompatibilitySuite.  This seems to be a 
well-documented test harness for running the CompatibilitySuite against 
different versions of jdbc clients and derby servers. It consists of 
multiple "for loops" implemented in ant, calling 
CompatibiltySuite.main() with different arguments.

CompatibilitySuite.main takes advantage of the public setClient(..) 
method in DerbyJUnitTest, and the client settings are initialized using 
another mechanism than the one in i.e findClientFromProperties(), or any 
other mechanism found in the Derby test harness.

The main() method in the CompatibilitySuite is called from this script 
with the drivername, and by using stringmatching against drivernames in 
the LEGAL_CLIENTS[i][DRIVER_NAME], the correct client is loaded, and set 
using setClient(..).

My goal is to be able to run Derby junit tests from the junit 
testrunner, and to allow easy integration of JUnit tests into the 
current harness in Derby. Maintaining another test harness written as an 
ant.xml script is not really my itch. My question is therefore: could I 
leave it to someone else to maintain testScript.xml, or could it 
alternatively be removed ?




View raw message