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 Tue, 17 Oct 2006 16:07:40 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

------------------------------------------------------------------------------
  
  <!> Note that the class `org.apache.derbyTesting.functionTests.util.DerbyJUnitTest`
is [http://www.mail-archive.com/derby-dev@db.apache.org/msg23272.html deprecated].
  
- To write a JUnit test that uses JDBC, make your test class extend `BaseJDBCTestCase`. This
class is subclass of [http://www.junit.org/junit/javadoc/3.8.1/junit/framework/TestCase.html
TestCase] in JUnit framework and you can add test methods, write your `setUp` and `tearDown`
methods and finally the `suite` method that returns a suite of tests to run (typically all
tests in the test class). `BaseJDBCTestCase` provides a set of often used functionality, for
instance the method `getConnection` to obtain a connection to the default database. If you
are missing something, ask on derby-dev or create a sub-task/link a Jira issue to DERBY-1122.
+ To write a JUnit test that uses JDBC, make your test class extend `BaseJDBCTestCase`. This
class is subclass of [http://www.junit.org/junit/javadoc/3.8.1/junit/framework/TestCase.html
TestCase] in JUnit framework and you can add test methods, optionally write your `setUp` and
`tearDown` methods and finally the `suite` method that returns a suite of tests to run (typically
all tests in the test class). `BaseJDBCTestCase` provides a set of often used functionality,
please look at what is available before writing your test. For instance the method `getConnection`
to obtain a connection to the default database, so there is no need for your own test class
to have a Connection field. If you are missing something, ask on derby-dev or create a sub-task/link
a Jira issue to DERBY-1122.
  
  `BaseTestCase` is to be used for JUnit tests not using the JDBC API.
  
- `BaseJDBCTestSetup` is the base class for test decorators that use JDBC. Look at the utility
methods that this class provides when writing a JDBC test that extends it. In particular,
there is no need for your own test class to have a Connection field. The connection is stored
in the super-class, either use `getConnection` or the utility methods such as `createStatement`.
+ `BaseJDBCTestSetup` is the base class for test decorators that use JDBC. Look at the utility
methods that this class provides when writing a JDBC test that extends it.
  
  `TestConfiguration` holds information about the test configuration/environment. It is responsible
for parsing information passed along from the test harness.
  
@@ -48, +48 @@

  === The suite() method ===
  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. Tests that
need to be written for a specific framework should be placed in a separate test class and
have their `suite()` method return an empty suite when running in a different framework.
+ 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()`.
  
+ In general, all tests should be written to be able to run under any framework. Tests that
need to be written for a specific framework should be placed in a separate test class and
have their `suite()` method return an empty suite when running in a different framework.
+ 
- Thus a test is self-contained about which frameworks it can be run in. This avoids the situation
with the [:KillDerbyTestHarness:old Derby harness] where discovering if a test is being run
in a framework and/or environment is very painful. While JUnit tests continue to be run under
the [:KillDerbyTestHarness:old Derby harness] when it is run should be controlled by the mechanisms
provided (exclude/skip files etc.) '''when''' no such facility exists in the JUnit environment.
+ A test must be self-contained about which frameworks it can be run in. This avoids the situation
with the [:KillDerbyTestHarness:old Derby harness] where discovering if a test is being run
in a framework and/or environment is very painful. While JUnit tests continue to be run under
the [:KillDerbyTestHarness:old Derby harness] when it is run should be controlled by the mechanisms
provided (exclude/skip files etc.) '''when''' no such facility exists in the JUnit environment.
  
  Tests that require a minimum level of JDBC support use the `vmSupportsJDBC2`, `vmSupportsJDBC3`,
`vmSupportsJDBC4` and/or `vmSupportsJSR169` methods in the `JDBC` class. The style for using
these methods should be "postive" and not "negative", e.g. "this test requires JDBC 3", not
"this test doesn't run
  on JDBC 2 or JSR 169". This mechanism is to be used instead of any skip facility in the
old test harness as it allows the tests to run correctly from standalone JUnit test runners.
  
  If a test has no test cases to run in a certain configuration or VM environment then it
should just return an empty suite.
+ 
+ See the [http://wiki.apache.org/db-derby/DerbyJunitTestConfiguration test configuration
page] for meore details about how to write `suite()` methods
+ and the definition of primary configurations.
  
  === Package Level _Suite ===
  
@@ -78, +83 @@

  
  === Configurations ===
  
- draft notes in DerbyJunitTestConfiguration
+ See DerbyJunitTestConfiguration
  
  === Usage of SQL states in JUnit tests ===
  In your tests, you might want to check for a specific SQL state when an SQLException is
thrown. The recommended way to handle this, is to use the `BaseJDBCTestCase.assertSQLState(String,String,SQLException)`
and either pass in a constant from `org.apache.derby.functionTesting.util.SQLStateConstants`,
or simply hardcode the value or use your own test-local constant. Doing this will assure tests
break if someone changes the SQL state for an exception in the internal class, and raises
the awareness of SQL state changes in the community.
@@ -91, +96 @@

  
  Tests can be run using the Junit 3.8 !TestRunners. The classpath needs to include the junit.jar
and the Derby classes.
  Most of Derby's JUnit test cases and suites run successfully using the !TestRunners directly,
as that is the eventual goal.
- Hopefully all new test
+ 
+ [http://issues.apache.org/jira/browse/DERBY-1952 DERBY-1952] is opened to start removing
JUnit tests from the old harness and
+ instead only support them running directly using JUnit test runners. The top level suite
+ `org.apache.derbyTesting.functionTests.suites.All` successfully runs most of the JUnit tests
standalone and those tests are not
+ run by the old test harness.
  
  The class name of the test passed to the runners can be an individual test case or one one
of the Derby suites, see examples.
  
@@ -101, +110 @@

  Such tests may fail in unpredictable ways when run by !TestRunners direcly. One way to identify
such tests is to see
  if they have any _app.properties or _derby.properties file, or they are listed in exclude
files.
  
+ <!> No system properties are required when running directly with !TestRunners, the
!BaseTestCase class
- <!> The only current (hopefully short lived) requirement for running tests using !TestRunners
directly is that the system 
- property `derby.system.home` is set to the current directory. No other properties are required,
the BaseTestCase class
  automatically installs a security manager with the correct policy file.
  
  ==== batch run ====
  {{{
  # Single test case
- > java -Dderby.system.home=$PWD -cp '../../tools/java/junit.jar:../../classes' junit.textui.TestRunner
+ > java -cp '../../tools/java/junit.jar:../../classes' junit.textui.TestRunner
          org.apache.derbyTesting.functionTests.tests.jdbcapi.ProcedureTest
  ...........................
  Time: 8.943
@@ -116, +124 @@

  OK (27 tests)
  
  # The jdbcapi package _Suite
- java -Dderby.system.home=$PWD junit.textui.TestRunner org.apache.derbyTesting.functionTests.tests.jdbcapi._Suite
+ java junit.textui.TestRunner org.apache.derbyTesting.functionTests.tests.jdbcapi._Suite
  
- # All the embedded cases
+ # All the test cases
- java -Dderby.system.home=$PWD junit.textui.TestRunner org.apache.derbyTesting.functionTests.suites.Embedded
+ java junit.textui.TestRunner org.apache.derbyTesting.functionTests.suites.All
  
  }}}
  ==== GUI (awt) run ====
  {{{
- > java -Dderby.system.home=$PWD -cp '../../tools/java/junit.jar;../../classes' junit.awtui.TestRunner
+ > java -noloading -cp '../../tools/java/junit.jar;../../classes' junit.awtui.TestRunner
  }}}
- The supply the complete name of the test class in the top window, e.g. `org.apache.derbyTesting.functionTests.tests.jdbcapi.ProcedureTest`.
+ Then supply the complete name of the test class in the top window, e.g. `org.apache.derbyTesting.functionTests.tests.jdbcapi.ProcedureTest`.
- 
+ <!> The use of the `-noloading` flag is required, if you recompile Derby or the test
classes you must restart the graphical test runners.
  === Running tests using the old Derby harness ===
  
  The [:KillDerbyTestHarness:old Derby harness] supports running JUnit tests directly and
from its suite.runall files.

Mime
View raw message