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 "DerbyJunitTestConfiguration" by DanDebrunner
Date Thu, 20 Dec 2007 18:00:28 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/DerbyJunitTestConfiguration

------------------------------------------------------------------------------
   * '''embedded & client''' - runs fixtures in both configurations, some individual fixtures
with a test class may only run in a single configuration due to items not supported in a configuration,
bugs in a configuration or no value in running the fixture in that configuration. Typically
tests that are aimed at testing JDBC methods or objects (e.g. functional test packages `jdbcapi`
and `jdbc4`) will run in both configurations so that both drivers are tested.
   * '''embedded only''' - Typically SQL language tests (e.g. function test package `lang`)
can run only in embedded since they are testing execution of SQL statements within the embedded
engine. For example testing of server side routines, DDL, triggers or GRANT/REVOKE would not
gain additional test coverage by running with the client driver. SQL language tests that relate
to data types most likely '''will''' benefit from running with the client as well to ensure
testing of transmission of the datatype across the DRDA protocol. Test of the storage sub-system
(`store` package) most likely will not need to run with the client configuration.
   * '''client only''' - E.g. specific testing of a client data source.
+ 
+ <!> Whenever test fixtures are added to a suite using the reference to the class (e.g.
`suite.addSuite(MyTest.class)`) then the order of execution
+ of the fixtures is not defined and may vary across different platforms. Thus this requires
that the fixtures be independent of each other, which
+ is a good practice to follow. Remember that the setUp() and tearDown() methods will be run
for each fixture. If a test needs ordering among
+ fixtures then adding the fixtures explicitly will preserve the order.
+ {{{
+     // adds all fixtures with no defined order of execution
+     suite.addSuite(MyTest.class);
+ 
+     // again, no order defined as MyTest.class is used
+     return TestConfiguration.defaultSuite(MyTest.class);
+ 
+     // adds fixtures that will executed in order testA first, then testB, and last testC
+     suite.add(new MyOrderedTest("testA"));
+     suite.add(new MyOrderedTest("testB"));
+     suite.add(new MyOrderedTest("testC"));
+ }}}
  
  Here are examples of how to write the `suite()` method for the test class `MyTest` for various
combinations.
  Any tests that are added into a suite without any client server decorator will run the fixtures
only as embedded.

Mime
View raw message