db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "A B (JIRA)" <derby-...@db.apache.org>
Subject [jira] Updated: (DERBY-1976) Add new utility methods to BaseJDBCTestCase to make conversion of ij tests to JUnit easier.
Date Thu, 19 Oct 2006 15:46:36 GMT
     [ http://issues.apache.org/jira/browse/DERBY-1976?page=all ]

A B updated DERBY-1976:
-----------------------

    Attachment: d1976_v2.patch

Attaching a second version of the patch, d1976_v2.patch, which has the following changes w.r.t
to the _v1 patch (following based on Dan's comments):

  - Moves "assertFullResultSet()" and its corresponding methods out of the BaseJDBCTestCase
class and into the JDBC class.

  - Changes JDBC.assertDrainResults() to accept a row count and, if the row count is non-negative,
to assert that the number of rows in the received result set matches the received row count.

  - Removes assertRowCount() from BaseJDBCTestCase (it's now incorporated into JDBC.assertDrainResults()
as mentioned above).

  - Renames "assertDDLRowCount()" to "assertUpdateCount()"

I ran "suites.All" with ibm142 and jdk142 and saw no failures.  Unless there are any other
review comments, I think this patch is ready for commit...

> 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
>         Assigned To: A B
>            Priority: Minor
>         Attachments: d1976_v1.patch, d1976_v2.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

        

Mime
View raw message