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.
