You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-commits@db.apache.org by Apache Wiki <wi...@apache.org> on 2006/09/01 15:21:37 UTC

[Db-derby Wiki] Update of "TestingFrameworks" by JohnHEmbretsen

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 JohnHEmbretsen:
http://wiki.apache.org/db-derby/TestingFrameworks

------------------------------------------------------------------------------
+ = Testing frameworks and suites =
- The Derby regression test suites contain multiple tests. The
- tests are arranged into suites for ease of use in running
- multiple related tests.
  
- Some of the test suites run the tests in alternate frameworks:
+ In Derby land, the word "framework" is usually used for specifying which JDBC driver
+ to use when running a test, or a suite of multiple tests. There are currently
+ three such frameworks that are recognized by the Derby test harness and being used in
+ the developer community:
  
-  * derbynetmats: basic network server tests using the IBM Universal JDBC driver
-  * derbynetclientmats: basic network server tests using the Derby client driver
+  * `Embedded` - Using the Derby Embedded JDBC driver
+  * `DerbyNetClient` - Using the Derby Client JDBC driver
+  * `DerbyNet` - Using the IBM Universal JDBC driver (also known as JCC)
+ 
+ In the `DerbyNet` and `DerbyNetClient` frameworks the Derby Network Server is accessed
+ using one of the client drivers. In the `Embedded` framework the Network Server is
+ not used.
+ 
+ 
+ == Specifying test framework ==
+ 
+ Which framework to use can usually be specified on the command line by using the 
+ `framework` system property, e.g.:
+ 
+ {{{
+ > java -Dframework=DerbyNetClient org.apache.derbyTesting.functionTests.harness.RunTest lang/wisconsin.java
+ }}}
+ 
+ The default framework is the Embedded framework. Framework names are case sensitive.
+ It is also possible to specify a specific framework when running suites, but keep in mind
+ that not all tests are suitable for all frameworks - more on that below.
+ 
+ 
+ == Test suites and frameworks ==
+ 
+ The Derby regression test suites contain multiple tests. The tests are arranged 
+ into suites for ease of use in running multiple related tests. A test suite can
+ consist of both individual tests and other test suites.
+ 
+ It can be quite confusing for a new developer to figure out in which framework a
+ specific test or test suite is being run while running "the mother of all test
+ suites", '''''derbyall''''', or some of its subsuites.
+ 
+ Some suites are set up for specific frameworks:
+ 
+  * `derbynetmats`: basic network server tests using the !DerbyNet framework. Note that this suite is also a subsuite of the derbynetclientmats suite.
+  * `derbynetclientmats`: basic network server tests using the !DerbyNetClient framework. Note that this suite is a superset of the derbynetmats suite.
+ 
+ (`mats` is a widely used testing abbreviation for "minimal acceptance test suite")
+ 
+ This means that during a `derbyall` run using default framework settings, most of the tests in 
+ the `derbynetmats` suite are run at least twice: Once in the !DerbyNet framework and once 
+ in the !DerbyNetClient framework.
+ 
+ The fact that individual tests may be excluded from being run in a certain framework 
+ by using `.exclude` files (in the [:KillDerbyTestHarness:"old" test harness] only) makes this even more 
+ complicated.
  
  The general rule for test authors is that it is best if a test
  can run in all three frameworks (embedded, and the two client configurations).
@@ -16, +62 @@

  just run in embedded framework only. Running these tests in other frameworks 
  might generate different outputs so you may have to generate different masters.
  
+ 
+ == How to find out the suites or frameworks in which a test will run? ==
+ 
- To see in which suites a particular test runs, you can examine the 'suites'
+ To see in which suite(s) a particular test runs, you can examine the 'suites'
+ directory of the code repository (e.g. [http://svn.apache.org/viewvc/db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/suites/ here]).
+ 
+ All non-JUnit suites are defined by a `.runall` file in the suites directory. This file lists
+ all the individual tests in the suite, for example (from derbynetclientmats.runall):
+ {{{
+ junitTests/derbyNet/CompatibilityTest.java
+ jdbcapi/xaSimplePositive.sql
+ jdbcapi/xaStateTran.sql
+ jdbcapi/lobStreams.java
+ jdbcapi/XATest.java
+ jdbcapi/checkDataSource.java
+ derbynet/ByteArrayCombinerStreamTest.junit
+ derbynet/SqlExceptionTest.junit
+ lang/grantRevoke.java
+ }}}
+ In addition, any subsuites to be included in a suite
+ are specified in a `.properties` file, also in the suites directory. For example, the
+ `suites/derbynetclientmats.properties` file includes the following line:
+ {{{
+ suites= encodingTests derbynetclientmats derbynetmats jdbc40
+ }}}
+ 
- directory. You could also invoke the tests without actually running them 
+ You can also invoke the test or a suite without actually running the test(s), 
  and then see if your test gets picked up in the framework of your interest. 
- RunTest has listOnly option.
+ The [:KillDerbyTestHarness:"old" test harness] has a listOnly option (`-DlistOnly=true`).
  
+ The JUnit tests are configured a little differently, see ["DerbyJUnitTesting"].
- There is a *lot* more information in the file: java/testing/README.htm in
- the source tree.
  
+ 
+ == More information ==
+ 
+ There is a lot more information in the file [http://svn.apache.org/viewvc/db/derby/code/trunk/java/testing/README.htm?view=co java/testing/README.htm] in the source tree.
+ 
+ Other helpful tips may be found via the DerbyTesting wiki page.
+