db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-1895) Convert jdbcapi/blobclob4BLOB.java to Junit
Date Mon, 16 Oct 2006 09:19:37 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1895?page=comments#action_12442521 ] 
            
Knut Anders Hatlen commented on DERBY-1895:
-------------------------------------------

Hi Fernanda. Thank you for rewriting the test! I had a quick look at your patch and the description
of it. A couple of question/comments:

- Some of the test cases (testSetClobToIntColumn, testSetClobToIntColumn, testSetClobToIntColumn)
have comments saying "need to run prepareCLOBMAIN first", but there is no such method.

- I'm not sure I understand what testClobFinalizer and testBlobFinalizer test. Is their only
purpose to force the finalizers to run? If so, would it make sense to add System.runFinalization()
after System.gc().

- The testPosition* cases use random start position and length. If these tests fail, it could
be hard to reproduce because we don't know the actual values. Could the start position and
length be part of the error message? (I saw the println() statements, but they only print
the information when the verbose flag is true.)

- runPositionStringTest() has a workaround for DERBY-1917. When the test has been committed,
a comment should be added to 1917 that the test should be cleaned up when it has been fixed.

- The suite() method adds each test case manually. I think it would be better to use the built-in
JUnit functionality for adding all test* methods and only add those test cases that don't
run under DerbyNet manually. That would make it easier to add more test cases later, and it
would be more consistent with the other JUnit tests.

- Minor nit: many calls to assertTrue("XXX", false) would be easier to read if written as
fail("XXX").

- I found many constructions similar to this:

+        try {
+            clob.length();
+            if (usingEmbedded()) {
+                assertTrue("FAIL - should not be able to access large log " +
+                        "after commit", false);
+            }
+        } catch (SQLException e) {
+            checkException(BLOB_ACCESSED_AFTER_COMMIT, e);
+        }

  If I understand these constructions correctly, they expect embedded to fail with a given
SQLState, but the network client and JCC should succeed. But under DerbyNet and DerbyNetClient,
these test cases will succeed both when the call succeeds and when the call fails with the
given SQLState. Is this how it was intended?

> Convert jdbcapi/blobclob4BLOB.java to Junit
> -------------------------------------------
>
>                 Key: DERBY-1895
>                 URL: http://issues.apache.org/jira/browse/DERBY-1895
>             Project: Derby
>          Issue Type: Sub-task
>            Reporter: Fernanda Pizzorno
>         Assigned To: Fernanda Pizzorno
>         Attachments: derby-1895.diff, derby-1895.html, derby-1895.stat
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message