Hi Dan,
Daniel John Debrunner wrote:
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().
Sounds good to me.
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?
It could say, instead, "will autoload the 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.
That's right. This is a bug and if you wanted to test property-based
autoloading, this logic would fail. Right now all that is tested is the
autoloading introduced by jdk1.6.
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 )
Yep, looks goofy.
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.
They could be moved someplace else. Have at it!
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.
We will need some other device for answering the question "Is the engine
up and running?"
Thanks,
Dan.
Are you volunteering to clean this up?
Thanks,
-Rick
