I have a few questions about the auto-loading setup for the JUnit tests
and the tests themselves:

1) TestConfiguration.autoloading() - I would see autoloading() as an
aspect of the VM setup and not of the test configuration. I see
TestConfiguration representing how we want the tests to run (embedded
vs. client, database name etc.), auto-loading doesn't seem to fit into
this. Can I move this method out of the class, it would make more sense
as a static method on JDBC. JDBC.vmSupportAutoloading().

2) The javadoc for TestConfiguration.autoloading() says:
"Return true if we expect that the DriverManager will autoload the
client driver." I don't see this method as being special to the client
driver, or does "client" here mean any JDBC driver?

3) TestConfiguration.autoloading() has this code (edited for space):

   if ( !JDBC.vmSupportsJDBC4() )
     return false;

   if ( getSystemStartupProperty( "jdbc.drivers" ) != null
     return true;

Isn't this the wrong way round. If "jdbc.drivers"  is set then that will
work in any jvm, it doesn't require JDBC 4.

4) Should this test in TestConfiguration.autoloading() check that the
required driver name is in the property?
if ( getSystemStartupProperty( "jdbc.drivers" ) != null

5) I assume this just needs cleaning: From AutoloadBooting,
note the variable name does not match its use.

                boolean         isAutoloading = 
!getTestConfiguration().autoloading();
                
                //
                // Forcibly load the network client if we are not autoloading 
it.
                //
                if ( isAutoloading )

6) The tests AutoloadBooting and AutoloadTest are in the jdbc4 package,
but there is nothing specific to JDBC 4 here, so should they be in the
jdbcapi directory? Since they are built using mustang they will not run
on lower vms, even though I assume they could be used to test the
jdbc.drivers property use with Derby.

7) One of the test uses engine internals to see if the embedded engine
has booted, I would recommend against that. It potentially ties the
tests to a specific version of Derby, whereas it will be great in the
future if we can run the 10.2 tests against a future version to ensure
there are no regressions.


Thanks,
Dan.




Reply via email to