[junit]- ability to check JDBC level replaces _app properties files

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

The JUnit setup now has methods that allow a test to check to see if the
vm supports levels of JDBC. The methods are in the class JDBC.

JDBC.vmSupportsJDBC2() // JDBC 2.0 or greater
JDBC.vmSupportsJDBC3() // JDBC 3.0 or greater
JDBC.vmSupportsJDBC4() // JDBC 4.0 or greater
JDBC.vmSupportsJSR169() // JSR 169

Junit tests can use these methods in their suites to control which tests
are run when it based upon a level of JDBC support, rather than using
the old harness method of _app.properties files and runjdk13=false etc.

Using these methods, instead of skipping in the the old harness, allows
the tests to be run correctly when run directly using JUnit test
runners, which of course is the eventual goal.

The additional benefit of the old harness mechanism is that the test can
be selective as to its setup, the UpdateXXXTest through the old harness
was not run on JSR169 altogether, using these methods all but one test
case are run on JSR169.

I believe the style for using these methods should be "postive" and not
"negative", e.g. "this test requires JDBC 3", not "this test doesn't run
on JDBC 2 or JSR 169". It's always good to comment what feature of the
JDBC sub-set is required. Here's a couple of example uses:

(from UpdateXXXTest)
        // requires java.math.BigDecimal
        if (JDBC.vmSupportsJDBC2())
            suite.addTest(new UpdateXXXTest("testUpdateBigDecimal"));

(from ConcurrencyTest not yet committed)
       // Requires holdability
        if (JDBC.vmSupportsJDBC3() || JDBC.vmSupportsJSR169()) {


One issue around jdbc 4 Junit tests is that there is no reason to have
vmSupportsJDBC4 logic in the test, since the classes are compiled on
Java SE 6 they won't even load in older enviroments.

I will update the wiki with this info.

For several of the existing Junit tests they are disabled in foundation
and/or jdk13 with *no* comments as to why. It's always preferable to put
a comment syaing why it's excluded, and I think it's a valid reason for
a new test to say "I haven't tested in foundation and/or jdk 13". This
then allows someone else, who cares about those environments, to try the
tests out. Without the comment one has to try and figure out if the test
won't be able to run in those environments due to some other requirement.


Dan.

Re: [junit]- ability to check JDBC level replaces _app properties files

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

Kristian Waagan wrote:


> The code is perfectly fine, but it can be reduced to:
> public static Test suite() {
>     TestSuite suite = new TestSuite(UpdateXXXTest.class);
> 
>     // requires java.math.BigDecimal
>     if (JDBC.vmSupportsJDBC2())
>         suite.addTest(new UpdateXXXTest("jdbc2UpdateBigDecimal"));
> 
>     return suite;
> }
> 
> Note that the method requiring JDBC2 or higher was renamed.
> You might loose a bit of verbosity with this technique (which tests are
> added?), and maybe an extra look at the code is required to understand
> which methods are indeed test methods.
> 
> Do people think this is an acceptable technique?

That's a great approach, it was a pain adding the cases individually and
I was concerned I might miss one, so your approach is much better.

Thanks,
Dan.

Re: [junit]- ability to check JDBC level replaces _app properties files

[Kristian Waagan <Kr...@Sun.COM>]

Daniel John Debrunner wrote:
> The JUnit setup now has methods that allow a test to check to see if the
> vm supports levels of JDBC. The methods are in the class JDBC.
> 
> JDBC.vmSupportsJDBC2() // JDBC 2.0 or greater
> JDBC.vmSupportsJDBC3() // JDBC 3.0 or greater
> JDBC.vmSupportsJDBC4() // JDBC 4.0 or greater
> JDBC.vmSupportsJSR169() // JSR 169
> 
> Junit tests can use these methods in their suites to control which tests
> are run when it based upon a level of JDBC support, rather than using
> the old harness method of _app.properties files and runjdk13=false etc.
> 
> Using these methods, instead of skipping in the the old harness, allows
> the tests to be run correctly when run directly using JUnit test
> runners, which of course is the eventual goal.
> 
> The additional benefit of the old harness mechanism is that the test can
> be selective as to its setup, the UpdateXXXTest through the old harness
> was not run on JSR169 altogether, using these methods all but one test
> case are run on JSR169.
> 
> I believe the style for using these methods should be "postive" and not
> "negative", e.g. "this test requires JDBC 3", not "this test doesn't run
> on JDBC 2 or JSR 169". It's always good to comment what feature of the
> JDBC sub-set is required. Here's a couple of example uses:
> 
> (from UpdateXXXTest)
>         // requires java.math.BigDecimal
>         if (JDBC.vmSupportsJDBC2())
>             suite.addTest(new UpdateXXXTest("testUpdateBigDecimal"));
> 
> (from ConcurrencyTest not yet committed)
>        // Requires holdability
>         if (JDBC.vmSupportsJDBC3() || JDBC.vmSupportsJSR169()) {

Hi Dan,

Nice work on the JUnit "infrastructure" and processes :)

One comment to the above, having to do with adding tests only if the 
required JDBC level is supported. If you have very many test methods, 
adding all of them manually can be a bit of a pain.

A way to reduce the work, is to name all test methods that can run with 
any JDBC level (or another property of the environment) as "test*". You 
can then use the usual method adding all of these by reflection. Next, 
you take care of the test methods that require special attention, which 
must not have a name starting with "test".

To illustrate, I saw this commit a little while ago:
public static Test suite() {
     TestSuite suite = new TestSuite();

     suite.addTest(new UpdateXXXTest("testUpdateShort"));
     suite.addTest(new UpdateXXXTest("testUpdateInt"));
     suite.addTest(new UpdateXXXTest("testUpdateLong"));
     suite.addTest(new UpdateXXXTest("testUpdateFloat"));
     suite.addTest(new UpdateXXXTest("testUpdateDouble"));
     suite.addTest(new UpdateXXXTest("testUpdateNull"));
     suite.addTest(new UpdateXXXTest("testUpdateObjectWithNull"));
     suite.addTest(new UpdateXXXTest("testUpdateString"));

     // requires java.math.BigDecimal
     if (JDBC.vmSupportsJDBC2())
         suite.addTest(new UpdateXXXTest("testUpdateBigDecimal"));

     return suite;
}

The code is perfectly fine, but it can be reduced to:
public static Test suite() {
     TestSuite suite = new TestSuite(UpdateXXXTest.class);

     // requires java.math.BigDecimal
     if (JDBC.vmSupportsJDBC2())
         suite.addTest(new UpdateXXXTest("jdbc2UpdateBigDecimal"));

     return suite;
}

Note that the method requiring JDBC2 or higher was renamed.
You might loose a bit of verbosity with this technique (which tests are 
added?), and maybe an extra look at the code is required to understand 
which methods are indeed test methods.

Do people think this is an acceptable technique?



Regards,
-- 
Kristian

> 
> 
> One issue around jdbc 4 Junit tests is that there is no reason to have
> vmSupportsJDBC4 logic in the test, since the classes are compiled on
> Java SE 6 they won't even load in older enviroments.
> 
> I will update the wiki with this info.
> 
> For several of the existing Junit tests they are disabled in foundation
> and/or jdk13 with *no* comments as to why. It's always preferable to put
> a comment syaing why it's excluded, and I think it's a valid reason for
> a new test to say "I haven't tested in foundation and/or jdk 13". This
> then allows someone else, who cares about those environments, to try the
> tests out. Without the comment one has to try and figure out if the test
> won't be able to run in those environments due to some other requirement.
> 
> 
> Dan.
> 
> 
>