auto-loading & tests confusion/questions

[Daniel John Debrunner <dj...@apache.org>]

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.

Re: auto-loading & tests confusion/questions

[Daniel John Debrunner <dj...@apache.org>]

Rick Hillegas wrote:

[questions & answers snipped]

>>
> Are you volunteering to clean this up?

Yes, thanks for the quick reply Rick.

Dan.

Re: auto-loading & tests confusion/questions

[Rick Hillegas <Ri...@Sun.COM>]

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

>
>
>  
>