GNU Info

(python2.1-lib.info)TestCase Objects

---

Next: TestSuite Objects Prev: Classes and functions 2 Up: unittest

---

Enter node , (file) or (file)node

TestCase Objects
----------------

Each `TestCase' instance represents a single test, but each concrete
subclass may be used to define multiple tests -- the concrete class
represents a single test fixture.  The fixture is created and cleaned
up for each test case.

`TestCase' instances provide three groups of methods: one group used to
run the test, another used by the test implementation to check
conditions and report failures, and some inquiry methods allowing
information about the test itself to be gathered.

Methods in the first group are:

`setUp()'
     Method called to prepare the test fixture.  This is called
     immediately before calling the test method; any exception raised by
     this method will be considered an error rather than a test failure.
     The default implementation does nothing.

`tearDown()'
     Method called immediately after the test method has been called and
     the result recorded.  This is called even if the test method raised
     an exception, so the implementation in subclasses may need to be
     particularly careful about checking internal state.  Any exception
     raised by this method will be considered an error rather than a
     test failure.  This method will only be called if the `setUp()'
     succeeds, regardless of the outcome of the test method.  The
     default implementation does nothing.

`run([result])'
     Run the test, collecting the result into the test result object
     passed as RESULT.  If RESULT is omitted or `None', a temporary
     result object is created and used, but is not made available to
     the caller.  This is equivalent to simply calling the `TestCase'
     instance.

`debug()'
     Run the test without collecting the result.  This allows exceptions
     raised by the test to be propogated to the caller, and can be used
     to support running tests under a debugger.

The test code can use any of the following methods to check for and
report failures.

`assert_(expr[, msg])'

`failUnless(expr[, msg])'
     Signal a test failure if EXPR is false; the explanation for the
     error will be MSG if given, otherwise it will be `None'.

`assertEqual(first, second[, msg])'

`failUnlessEqual(first, second[, msg])'
     Test that FIRST and SECOND are equal.  If the values do not
     compare equal, the test will fail with the explanation given by
     MSG, or `None'.  Note that using `failUnlessEqual()' improves upon
     doing the comparison as the first parameter to `failUnless()':
     the default value for MSG can be computed to include
     representations of both FIRST and SECOND.

`assertNotEqual(first, second[, msg])'

`failIfEqual(first, second[, msg])'
     Test that FIRST and SECOND are not equal.  If the values do
     compare equal, the test will fail with the explanation given by
     MSG, or `None'.  Note that using `failIfEqual()' improves upon
     doing the comparison as the first parameter to `failUnless()' is
     that the default value for MSG can be computed to include
     representations of both FIRST and SECOND.

`assertRaises(exception, callable, ...)'

`failUnlessRaises(exception, callable, ...)'
     Test that an exception is raised when CALLABLE is called with any
     positional or keyword arguments that are also passed to
     `assertRaises()'.  The test passes if EXCEPTION is raised, is an
     error if another exception is raised, or fails if no exception is
     raised.  To catch any of a group of exceptions, a tuple containing
     the exception classes may be passed as EXCEPTION.

`failIf(expr[, msg])'
     The inverse of the `failUnless()' method is the `failIf()' method.
     This signals a test failure if EXPR is true, with MSG or `None'
     for the error message.

`fail([msg])'
     Signals a test failure unconditionally, with MSG or `None' for the
     error message.

`failureException'
     This class attribute gives the exception raised by the `test()'
     method.  If a test framework needs to use a specialized exception,
     possibly to carry additional information, it must subclass this
     exception in order to "play fair" with the framework.  The initial
     value of this attribute is `AssertionError'.

Testing frameworks can use the following methods to collect information
on the test:

`countTestCases()'
     Return the number of tests represented by the this test object.
     For `TestCase' instances, this will always be `1', but this method
     is also implemented by the `TestSuite' class, which can return
     larger values.

`defaultTestResult()'
     Return the default type of test result object to be used to run
     this test.

`id()'
     Return a string identifying the specific test case.  This is
     usually the full name of the test method, including the module and
     class names.

`shortDescription()'
     Returns a one-line description of the test, or `None' if no
     description has been provided.  The default implementation of this
     method returns the first line of the test method's docstring, if
     available, or `None'.