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 Fri, 21 Jul 2006 14:05: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

------------------------------------------------------------------------------
  This page will describe how to run Derby JUnit tests, and how to write new JUnit tests for
Derby. All features of the test harness related to JUnit testing should be described here
as well.
+ 
+ [[TableOfContents]]
  
  == The junit test type ==
  The name of a Derby test is the argument supplied to `org.apache.derbyTesting.functionTests.harness.RunTest`
when the test is run. Derby JUnit test names always end with `.junit`, e.g. `somesuite/SomeTest.junit`.
In other words, the test type is `junit`. The file that implements a test is a java file,
e.g. `SomeTest.java`. The test harness uses the last part of the ''name'' to decide how it
should run the test. If the name ends with `.java`, the harness knows that the test is a java
class with a `main()` method. If the name ends with `.junit`, the harness knows it is a java
class which can be run by a JUnit test runner.
@@ -32, +34 @@

    * http://www.junit.org/junit/javadoc/3.8.1/index.htm 
  
  === The suite() method ===
- The `suite()` method is s static method returning the tests to be run. We use it to gain
more flexibility in which test methods are executed and the environment they are executed
in. For instance, the use of the `suite()` method allows us to use test decorators (the most
common case is setting up and populating a common database used by all tests in the suite).
+ The `suite()` method is a static method returning the tests to be run. We use it to gain
more flexibility in which test methods are executed and the environment they are executed
in. For instance, the use of the `suite()` method allows us to use test decorators (the most
common case is setting up and populating a common database used by all tests in the suite).
  
  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, and tests written
for a specific framework should be placed in a separate test class. When it is run should
be controlled by the mechanisms provided by the test harness (exclude/skip files).
  
@@ -43, +45 @@

  
  == Running tests using Junit directly ==
  
- Tests can be run using the Junit 3.8 TestRunners. The classpath needs to include the junit.jar
and the Derby classes.
+ Tests can be run using the Junit 3.8 !TestRunners. The classpath needs to include the junit.jar
and the Derby classes.
  
- /!\ Since running a test like this is outside of the Derby test harness, setup the test
expects may not be provided and thus the
+ /!\ Since running a test like this is (currently) outside of the Derby test harness, setup
the test expects may not be provided and thus the
  test may change its behaviour in unpredictable ways.
  
  === batch run ===
@@ -64, +66 @@

  }}}
  The supply the complete name of the test class in the top window, e.g. `org.apache.derbyTesting.functionTests.tests.jdbcapi.ProcedureTest`.
  
+ == Switching the Derby harness over to JUnit ==
  
+ An ultimate goal would be for all Derby tests to be JUnit tests and all existing logic in
the Derby test harness is replaced
+ by JUnit code, such as test decorators to perform test setup and cleanup. A 
+ [http://mail-archives.apache.org/mod_mbox/db-derby-dev/200607.mbox/%3c44BFD7EE.3020708@apache.org%3e
discussion was started on derby-dev].
+ This would gain all the benefits of JUnit, such as running tests from ant, integration with
IDEs, ability to hook into other JUnit suites,
+ easier understanding of how Derby tests are run etc.
+ 
+ Click here on more information on the roadmap to [:KillDerbyTestHarness:completing the switch
to JUnit].
  
  == Requested features for the JUnit harness ==
  Features requested for the JUnit harness on derby-dev. Note that this page is intended to
be a summary page only. In general, all information presented here should be found in the
mail archives for derby-dev as well (you can search here: http://www.nabble.com/Derby-f356.html).

Mime
View raw message