[ http://issues.apache.org/jira/browse/DERBY-1976?page=all ]
A B updated DERBY-1976:
-----------------------
Attachment: d1976_v1.patch
Attaching a patch, d1976_v1.patch, that adds the methods described in the
description for this issue. For more details, please see the code comments.
I ran the JUnit suite "suites.All" against ibm142, jdk142, ibm15, jdk15, and
jdk16 on a Windows 2000 machine. The only failure I saw was an intermittent
failure in LobLengthTest on jdk15:
There was 1 error:
1)
testLongLobLengths(org.apache.derbyTesting.functionTests.tests.jdbcapi.LobLengthTest)
java.sql.SQL Exception: DERBY SQL error: SQLCODE: -1, SQLSTATE: XJ001,
SQLERRMC:
org.apache.derby.shared.common.sanity.AssertFailure#ASSERT FAILED Container
closed
while IO operations are in progress. This should not happen.#XJ001.U
at
org.apache.derby.client.am.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:46)
at
org.apache.derby.client.am.SqlException.getSQLException(SqlException.java:345)
at org.apache.derby.client.am.Connection.commit(Connection.java:555)
at
org.apache.derbyTesting.junit.BaseJDBCTestCase.commit(BaseJDBCTestCase.java:159)
at
org.apache.derbyTesting.functionTests.tests.jdbcapi.LobLengthTest.tearDown(LobLengthTest.java:87)
at
org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:76)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
at junit.extensions.TestSetup.run(TestSetup.java:23)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
at junit.extensions.TestSetup.run(TestSetup.java:23)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
at junit.extensions.TestSetup.run(TestSetup.java:23)
Caused by: org.apache.derby.client.am.SqlException: DERBY SQL error:
SQLCODE: -1,
SQLSTATE: XJ001, SQLERRMC:
org.apache.derby.shared.common.sanity.AssertFailure#ASSERT
FAILED Container closed while IO operations are in progress. This should
not happen.#XJ001.U
at
org.apache.derby.client.am.Connection.completeSqlca(Connection.java:1920)
at
org.apache.derby.client.net.NetConnectionReply.parseRDBCMMreply(NetConnectionReply.java:215)
at
org.apache.derby.client.net.NetConnectionReply.readLocalCommit(NetConnectionReply.java:147)
at
org.apache.derby.client.net.ConnectionReply.readLocalCommit(ConnectionReply.java:43)
at
org.apache.derby.client.net.NetConnection.readLocalCommit_(NetConnection.java:1574)
at org.apache.derby.client.am.Connection.readCommit(Connection.java:639)
at org.apache.derby.client.am.Connection.flowCommit(Connection.java:588)
at org.apache.derby.client.am.Connection.commit(Connection.java:551)
... 33 more
This error occurred once as part of suites.All but did not occur when I ran the
test separately and also did not occur when I re-ran the suite a second time.
So I don't know if this is specific to jdk15 or not-- but in any event, I don't
think this is related to my changes.
Review comments/feedback/commit would be much appreciated...
> Add new utility methods to BaseJDBCTestCase to make conversion of ij tests to
> JUnit easier.
> -------------------------------------------------------------------------------------------
>
> Key: DERBY-1976
> URL: http://issues.apache.org/jira/browse/DERBY-1976
> Project: Derby
> Issue Type: Sub-task
> Components: Test
> Affects Versions: 10.3.0.0
> Reporter: A B
> Priority: Minor
> Attachments: d1976_v1.patch
>
>
> As part of my work for DERBY-1758 I'm trying to convert the SQL test
> lang/xml_general.sql into a JUnit test. In doing so I've found that there
> are several methods which would make such a conversion easier (and more
> applicable across different frameworks).
> In particular the methods I've found useful (and for which I plan to post a
> patch) are:
> -- assertSQLState():
> This method already exists, but I'd like to expand it so that if the
> top-level exception doesn't have the target SQLSTATE, the method will look at
> nested exceptions (if any) and try to determine if any of them match the
> target SQLSTATE.
> This added functionality is useful in cases where we have a generic
> top-level SQLException that in turn has a more specific (and probably more
> meaningful) nested exception that is really what we want to test.
> For example, master/xml_general.out has the following lines:
> ij> -- XML cannot be imported or exported. These should all fail.
> CALL SYSCS_UTIL.SYSCS_EXPORT_TABLE (
> null, 'T1', 'xmlexport.del', null, null, null);
> ERROR 38000: The exception 'java.sql.SQLException: XML values are not
> allowed in top-level result sets; try using XMLSERIALIZE.' was thrown while
> evaluating an expression.
> ERROR 42Z71: XML values are not allowed in top-level result sets; try
> using XMLSERIALIZE.
> Since both 38000 and 42Z71 show up in the master file we're effectively
> checking both of them. With JUnit we could check both by doing something
> like:
> assertSQLState("38000", se);
> assertSQLState("42Z71", se.getNextException());
> but that doesn't appear to work for client/server configurations because we
> don't actually get chained exceptions in client/server; we just get a single
> exception whose content is the concatenation of the top-level exception's
> message with the nested exception's message. That said, if we extend
> assertSQLSTATE() to check nested exceptions and make that check account for
> the different treatment of nested exceptions in client vs embedded vs jcc,
> then we can check both SQLSTATEs by making two calls with the same
> SQLException, namely:
> assertSQLSTATE("38000", se);
> assertSQLSTATE("42Z71", se);
> Or if we don't care about 38000 but are really just interested in 42Z71,
> then we just make the single call for the latter and ignore the former.
> Either way the call to assertSQLState() should be enhanced such that it can
> handle nested exceptions for all frameworks/configurations.
> -- assertCompileError():
> Again, this method already exists. But I'd like to extend it so that if
> the call to "prepareStatement(query)" succeeds, the method goes on to call
> "execute()" on the prepared statement. The reason for this is that JCC
> defers preparation until execution time. Thus if we expect a compile-time
> error in a test and we run it against JCC, the current method will throw an
> assertionfailure because JCC didn't actually try to compile the query (and
> thus didn't throw an error). By adding a call to "execute()" we force JCC to
> compile and therefore make it so that the method behaves as expected in all
> frameworks.
> -- assertStatementError():
> A more generic version of assertCompileError() that doesn't care when the
> error happens. This method executes the query and processes (reads and
> discards) all rows in the result set(s) (if any) until it hits an error. If
> no error is thrown then an assertion failure occurs.
> This method is useful for checking execution-time errors--especially
> data-specific ones such a divide-by-zero. For example, assume we have a
> query that returns 3 rows successfully but is expected to throw an error on
> fourth row. In embedded mode execution of the query will occur without an
> error and the first three calls to "rs.next()" will also succeed. Only when
> the fourth call to "rs.next()" is made will the error occur. In JCC, though,
> the error occurs right away as part of the call to "execute()". By having a
> method that doesn't care *when* the error occurs--it just asserts that the
> error does in fact occur at some point--we make it easier to check for
> execution-time errors across all frameworks.
> -- assertDDLRowCount():
> Executes a statement using "executeUpdate()" and asserts that the resultant
> row count matches an expected row count. This method is itself just one line:
> + assertEquals("DDL row count doesn't match.",
> + expectedRC, st.executeUpdate(query));
> but by putting it in a common place we avoid having to re-type (or
> copy-paste) the assertion failure message every single time we want to check
> row counts. Not by any means necessary, but convenient enough to warrant
> inclusion in BaseJDBCTestCase, I think.
> -- assertRowCount():
> Takes a result set and an expected row count and simply iterates through
> the result set, counting the number of rows. Then asserts that the actual
> and expected row counts are the same.
> -- assertFullResultSet():
> Takes a result set and a two-dimensional array and asserts that the two
> have equivalent rows and columns. The first row in the 2-d array is expected
> to be the names of the columns and thus is compared to the metadata column
> names. Subsequent rows in the array are then compared with the corresponding
> rows in the result set.
> This method is useful when converting the output of a query from a .sql
> test into a JUnit test. Test writers (or perhaps more importantly, some
> wouldn't-it-be-nice conversion tool) can create the 2-D array based on the
> master file and then call this method to verify that the rows and columns in
> the result set are all as expected.
--
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
