derby-2398-pre.diff converts about half of jdbcapi/autoGeneratedJdbc30.java test to JUnit.
1) It adds a prepareStatement(String sql, int autoGeneratedKeys) method to junit/BaseJDBCTestCase.java.
2) This suite runs only if (JDBC.vmSupportsJDBC3()). Is checking for JDBC3 sufficient to handle J2ME/JSR169? --There's one test that will do a DriverManager call.
3) I made quite a few changes to the original test that are detailed below. For now, I have left in temporary System.out.println statements such as this:
System.out.println ("Old Test 1"); // temporary
along with prints of values to make it easy to doublecheck results against the original master.
Changes to original program:
4) The original test did SET INCREMENT BY in ALTER statements because "set by increment not yet supported for create table..."
The new JUnit test includes the increment in the CREATE TABLE statement.
5) There are many tests in the old version, roughly 25 * 4 queries each (most insert queries are tested four ways), so I divided them up into separate, standalone fixtures.
However! This means each fixture creates its own Statement and PreparedStatement. The old master output this note:
System.out.println("Test 8 - create a new statement and request for generated keys on it after doing an insert into ");
This led me to think there might have been a difference in behavior between reusing the same Statement and create a new one, but I haven't see any difference in behavior compared to the original master.
If the standalone fixtures path I'm on is not right, I'm only half way through the tests and it would be easy to redo the test so that a single fixture calls the separate test methods with the same Statements and PreparedStatements. Having separate methods will still make the test easier to read and follow.
6) I assume that what matters about the key generated is null vs. not-null value (I'm not paying attention to the actual values). That's simple, but if it's wrong I can change the code to test for actual values.