[
https://issues.apache.org/jira/browse/DERBY-2398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean T. Anderson updated DERBY-2398:
------------------------------------
Attachment: derby-2398-pre.diff
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.
> Convert jdbcapi/autoGeneratedJdbc30.java to junit
> -------------------------------------------------
>
> Key: DERBY-2398
> URL: https://issues.apache.org/jira/browse/DERBY-2398
> Project: Derby
> Issue Type: Improvement
> Components: Test
> Reporter: Jean T. Anderson
> Assigned To: Jean T. Anderson
> Priority: Minor
> Attachments: derby-2398-pre.diff, test_file_ignore_me.txt
>
>
> Convert the jdbcapi/autoGeneratedJdbc30.java test from the old harness to
> junit.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
