Movatterモバイル変換

23.3.5 TestCase Objects

EachTestCase instance represents a single test, but eachconcrete subclass may be used to define multiple tests -- theconcrete class represents a single test fixture. The fixture iscreated and cleaned up for each test case.

TestCase instances provide three groups of methods: one groupused to run the test, another used by the test implementation tocheck conditions and report failures, and some inquiry methodsallowing information about the test itself to be gathered.

Methods in the first group (running the test) 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 thesetUp() 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 asresult. Ifresult is omitted orNone, a temporary result object is created (by calling thedefaultTestCase() method) and used; this result object is not returned torun()'s caller.
The same effect may be had by simply calling theTestCase instance.

debug( ): Run the test without collecting the result. This allows exceptions raised by the test to be propagated 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 andreport failures.

assert_( expr[, msg])
failUnless( expr[, msg]): Signal a test failure ifexpr is false; the explanation for the error will bemsg if given, otherwise it will beNone.

assertEqual( first, second[, msg])
failUnlessEqual( first, second[, msg]): Test thatfirst andsecond are equal. If the values do not compare equal, the test will fail with the explanation given bymsg, orNone. Note that usingfailUnlessEqual() improves upon doing the comparison as the first parameter tofailUnless(): the default value formsg can be computed to include representations of bothfirst andsecond.

assertNotEqual( first, second[, msg])
failIfEqual( first, second[, msg]): Test thatfirst andsecond are not equal. If the values do compare equal, the test will fail with the explanation given bymsg, orNone. Note that usingfailIfEqual() improves upon doing the comparison as the first parameter tofailUnless() is that the default value formsg can be computed to include representations of bothfirst andsecond.

assertAlmostEqual( first, second[,places[, msg]])
failUnlessAlmostEqual( first, second[,places[, msg]]): Test thatfirst andsecond are approximately equal by computing the difference, rounding to the given number ofplaces, and comparing to zero. Note that comparing a given number of decimal places is not the same as comparing a given number of significant digits. If the values do not compare equal, the test will fail with the explanation given bymsg, orNone.

assertNotAlmostEqual( first, second[,places[, msg]])
failIfAlmostEqual( first, second[,places[, msg]]): Test thatfirst andsecond are not approximately equal by computing the difference, rounding to the given number ofplaces, and comparing to zero. Note that comparing a given number of decimal places is not the same as comparing a given number of significant digits. If the values do not compare equal, the test will fail with the explanation given bymsg, orNone.

assertRaises( exception, callable, ...)
failUnlessRaises( exception, callable, ...): Test that an exception is raised whencallable is called with any positional or keyword arguments that are also passed toassertRaises(). The test passes ifexception 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 asexception.

failIf( expr[, msg]): The inverse of thefailUnless() method is thefailIf() method. This signals a test failure ifexpr is true, withmsg orNone for the error message.

fail( [msg]): Signals a test failure unconditionally, withmsg orNone for the error message.

failureException: This class attribute gives the exception raised by thetest() 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 isAssertionError.

Testing frameworks can use the following methods to collectinformation on the test:

countTestCases( ): Return the number of tests represented by this test object. ForTestCase instances, this will always be1.

defaultTestResult( ): Return an instance of the test result class that should be used for this test case class (if no other result instance is provided to therun() method).
ForTestCase instances, this will always be an instance ofTestResult; subclasses ofTestCase should override this as necessary.

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

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

Release 2.5.2, documentation updated on 21st February, 2008.

SeeAbout this document... for information on suggesting changes.

[8]ページ先頭