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 "DerbyJUnitTesting" by DanDebrunner
Date Mon, 07 Aug 2006 19:02:20 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/DerbyJUnitTesting

------------------------------------------------------------------------------
  
  By default, all test methods whose name starts with `test` are added to the suite, typically
with `new TestSuite(MyDerbyTests.class, "My suite name")`. If there are tests that should
only be run in certain scenarioes, logic for doing this should be placed in `suite()`. The
prominent example is a test method that is only to be run in the !DerbyNetClient framework.
To fix this, name the method for instance `clientSomeTest` and add it manually to the suite
if `BaseJDBCTestCase.usingDerbyNetClient()` returns true with `suite.addTest(new MyDerbyTests("clientSomeTest"))`.
In general, all tests should be written to be able to run under any framework. Tests that
need to be written for a specific framework should be placed in a separate test class and
have their `suite()` method return an empty suite when running in a different framework.
  
- Thus a test is self-contained about which frameworks and it can be run in. This avoids the
situation with the [:KillDerbyTestHarness:old Derby harness] where discovering if a test is
being run in a framework and/or environment is very painful. WHile JUnit tests continue to
be run under the [:KillDerbyTestHarness:old Derby harness] when it is run should be controlled
by the mechanisms provided (exclude/skip files).
+ Thus a test is self-contained about which frameworks it can be run in. This avoids the situation
with the [:KillDerbyTestHarness:old Derby harness] where discovering if a test is being run
in a framework and/or environment is very painful. While JUnit tests continue to be run under
the [:KillDerbyTestHarness:old Derby harness] when it is run should be controlled by the mechanisms
provided (exclude/skip files etc.) '''when''' no such facility exists in the JUnit environment.
+ 
+ Tests that require a minimum level of JDBC support use the `vmSupportsJDBC2`, `vmSupportsJDBC3`,
`vmSupportsJDBC4` and/or `vmSupportsJSR169` methods in the `JDBC` class. The style for using
these methods should be "postive" and not "negative", e.g. "this test requires JDBC 3", not
"this test doesn't run
+ on JDBC 2 or JSR 169". This mechanism is to be used instead of any skip facility in the
old test harness as it allows the tests to run correctly from standalone JUnit test runners.
+ 
+ If a test has no test cases to run in a certain configuration or VM environment then it
should just return an empty suite.
  
  === Package Level _Suite ===
  
@@ -55, +60 @@

  
  While the the [:KillDerbyTestHarness:old Derby harness] continues to exist the _Suite class
should only include JUnit tests that successfully run
  using JUnit test runners directly. As `_Suite` classes evolve they may replace individual
test entries in the old suite runall files, so the old
- harness runs the _Suite instead of the JUnit tests individually. If a test requires existing
functionality of the old harness (such as skip in J2ME mode)
+ harness runs the _Suite instead of the JUnit tests individually. If a test requires existing
functionality of the old harness
  that does not yet have a corresponding mechansim with JUnit then it should not be in the
package suite.
  
  Some issues about _Suite:
@@ -63, +68 @@

     * Should the _Suite automatically return a suite that runs all the tests in all the frameworks
(individual tests can opt out of a framework)?
       * then how to run only embedded jdbcapi tests ?
     * Or should a higher level suite add the ability to run in different frameworks?
-      * Then how to handle tests that only run in a specific framework, maybe a separate
package?
+      * Then how to handle tests that only run in a specific framework, maybe a separate
package or just empty suite file for that test?
  
  === Usage of SQL states in JUnit tests ===
  In your tests, you might want to check for a specific SQL state when an SQLException is
thrown. The recommended way to handle this, is to use the `BaseJDBCTestCase.assertSQLState(String,String,SQLException)`
and either pass in a constant from `org.apache.derby.functionTesting.util.SQLStateConstants`,
or simply hardcode the value or use your own test-local constant. Doing this will assure tests
break if someone changes the SQL state for an exception in the internal class, and raises
the awareness of SQL state changes in the community.

Mime
View raw message