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 Sat, 13 Jan 2007 00:55:50 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

------------------------------------------------------------------------------
  
  A single suite defined by a class `_Suite` in a package should exist for all the JUnit tests
in that package.
  That is it has a `suite()` method that returns all the tests in the package by invoking
their `suite()` method and adding
- the result to an instance of TestSuite or adding them by using `classname>.class`.
+ the result to an instance of TestSuite.
  E.g. for the package `org.apache.derbyTesting.functionTests.tests.jdbcapi` a class `org.apache.derbyTesting.functionTests.tests.jdbcapi._Suite`
would exist that runs all the tests in that package.
  
+ See DerbyJunitTestConfiguration for details on top level suites.
- 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
- that does not yet have a corresponding mechansim with JUnit then it should not be in the
package suite.
- 
- Some issues about _Suite:
-  * For a suite such as jdbcapi how should running in different frameworks be handled?
-    * 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 or just empty suite file for that test?
  
  === Configurations ===
  

Mime
View raw message