db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject [junit]- ability to check JDBC level replaces _app properties files
Date Mon, 07 Aug 2006 18:49:03 GMT
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.




Mime
View raw message