db-derby-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Db-derby Wiki] Update of "ConvertOldTestToJunitTips" by DanDebrunner
Date Fri, 06 Jul 2007 17:28:16 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Db-derby Wiki" for change notification.

The following page has been changed by DanDebrunner:
http://wiki.apache.org/db-derby/ConvertOldTestToJunitTips

------------------------------------------------------------------------------
     * Not using the utility methods to get a connection. 
       Normally to get a connection to the default database, you should use [http://db.apache.org/derby/javadoc/testing/org/apache/derbyTesting/junit/BaseJDBCTestCase.html#getConnection()
getConnection()] This is a single connection that is reused so if you call getConnection twice,
you will get the same connection.  If you want a secondary connection, use [http://db.apache.org/derby/javadoc/testing/org/apache/derbyTesting/junit/BaseJDBCTestCase.html#openDefaultConnection()
openDefaultConnection]
     * Not removing the old test files. 
-      You should remove the old test files, canons and remove the old test from its suite.
This includes references in any junit *!HarnessJavaTest classes. ant clobbber before you build,
to make sure their are no residual dependencies on the old test files.
+      You should remove the old test files, canons and remove the old test from its suite.
This includes references in any junit *!HarnessJavaTest classes. ant clobber before you build,
to make sure their are no residual dependencies on the old test files.
-    * Omitting the fail after statement execution if a statement is expected to fail.  The
following code would not fail if the statement succeeds.
+    * Omitting the `fail` assert method after a method call in a try-catch block if that
method is expected to fail by throwing an exception.  The following code would not fail if
the Statement.execute() method succeeds.
  {{{
  try {
    s.execute(command);
@@ -71, +71 @@

  }
   }}}
  
- or better
+ or for this specific example a utility method already exists
  {{{
     assertStatementError("42502",s,command);
  }}}
  
+  * Putting multiple methods in a try-catch block when expecting the last to fail, the test
has some chance of passing if one of the methods that is expected to work incorrectly fails
with a matching exception.
+ {{{
+ try {
+    PreparedStatement ps = prepareCall(sql);
+    ps.setInt(1, 23);
+    ps.setString(2, 'hello');
+    // this call should fail
+    ps.executeUpdate();
+    fail("expected the executeUpdate() to fail");
+ } catch (SQLException e) {
+    assertSQLState("07000", e);
+ }
+ }}}
+ Instead move the methods expected to work outside of the try catch block.
+ {{{
+ PreparedStatement ps = prepareStatement(sql);
+ ps.setInt(1, 23);
+ ps.setString(2, 'hello');
+ try {
+    ps.executeUpdate();
+    fail("expected the executeUpdate() to fail");
+ } catch (SQLException e) {
+    assertSQLState("07000", e);
+ }
+ }}}
  
+  * Catching and discarding exceptions, especially on a close. If such a method throws an
exception then it's a bug in Derby, and thus the test should fail.
+ {{{
+   } finally {
+     if (rs != null)
+     { try {rs.close()} catch (SQLException e) {} }
+   }
+ }}}
+ Just call the close methods in line with the rest of the code, no need for any finally blocks.
+ {{{
+    PreparedStatement ps = prepareStatement(sql);
+    ...
+    ResultSet rs = ps.executeQuery();
+    ...
+    rs.close();
+    ps.close();
+ }}}
  
  
  == When writing tests is there a short cut to creating the ResultSet two dimensional arrays?
==

Mime
View raw message