Mailing-List: contact derby-commits-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Development" <derby-dev@db.apache.org>
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Apache Wiki <wikidiffs@apache.org>
To: derby-commits@db.apache.org
Date: Fri, 21 Jul 2006 14:05:20 -0000
Message-ID: <20060721140520.18531.56050@ajax.apache.org>
Subject: [Db-derby Wiki] Update of "DerbyJUnitTesting" by DanDebrunner

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).