Fred Drake | b9ad228 | 2001-04-07 05:41:39 +0000 | [diff] [blame^] | 1 | \section{\module{unittest} --- |
| 2 | Unit testing framework} |
| 3 | |
| 4 | \declaremodule{standard}{unittest} |
| 5 | \moduleauthor{Steve Purcell}{stephen\textunderscore{}purcell@yahoo.com} |
| 6 | \sectionauthor{Steve Purcell}{stephen\textunderscore{}purcell@yahoo.com} |
| 7 | \sectionauthor{Fred L. Drake, Jr.}{fdrake@acm.org} |
| 8 | |
| 9 | |
| 10 | The Python unit testing framework, often referred to as ``PyUnit,'' is |
| 11 | a Python language version of JUnit, by Kent Beck and Erich Gamma. |
| 12 | JUnit is, in turn, a Java version of Kent's Smalltalk testing |
| 13 | framework. Each is the de facto standard unit testing framework for |
| 14 | its respective language. |
| 15 | |
| 16 | PyUnit supports test automation, sharing of setup and shutdown code |
| 17 | for tests, aggregation of tests into collections, and independence of |
| 18 | the tests from the reporting framework. The \module{unittest} module |
| 19 | provides classes that make it easy to support these qualities for a |
| 20 | set of tests. |
| 21 | |
| 22 | To achieve this, PyUnit supports three major concepts: |
| 23 | |
| 24 | \begin{definitions} |
| 25 | \term{test case} |
| 26 | A \dfn{test case} is the smallest unit of testing. It checks for a |
| 27 | specific response to a particular set of inputs. PyUnit provides a |
| 28 | base class, \class{TestCase}, which may be used to create new test |
| 29 | cases. |
| 30 | |
| 31 | \term{test suite} |
| 32 | A \dfn{test suite} is a collection of test cases, test suites, or |
| 33 | both. It is used to aggregate tests that should be executed |
| 34 | together. |
| 35 | |
| 36 | \term{test runner} |
| 37 | A \dfn{test runner} is a component which orchestrates the execution of |
| 38 | tests and provides the outcome to the user. The runner may use a |
| 39 | graphical interface, a textual interface, or return a special value to |
| 40 | indicate the results of executing the tests. |
| 41 | \end{definitions} |
| 42 | |
| 43 | |
| 44 | |
| 45 | \begin{seealso} |
| 46 | \seetitle[http://pyunit.sourceforge.net/]{PyUnit Web Site}{The |
| 47 | source for further information on PyUnit.} |
| 48 | \seetitle[http://www.XProgramming.com/testfram.htm]{Simple Smalltalk |
| 49 | Testing: With Patterns}{Kent Beck's original paper on |
| 50 | testing frameworks using the pattern shared by |
| 51 | \module{unittest}.} |
| 52 | \end{seealso} |
| 53 | |
| 54 | |
| 55 | \subsection{Mapping concepts to classes |
| 56 | \label{test-concept-classes}} |
| 57 | |
| 58 | |
| 59 | \subsection{Organizing test code |
| 60 | \label{organizing-tests}} |
| 61 | |
| 62 | |
| 63 | \subsection{Re-using old test code |
| 64 | \label{legacy-unit-tests}} |
| 65 | |
| 66 | Some users will find that they have existing test code that they would |
| 67 | like to run from PyUnit, without converting every old test function to |
| 68 | a \class{TestCase} subclass. |
| 69 | |
| 70 | For this reason, PyUnit provides a \class{FunctionTestCase} class. |
| 71 | This subclass of \class{TestCase} can be used to wrap an existing test |
| 72 | function. Set-up and tear-down functions can also optionally be |
| 73 | wrapped. |
| 74 | |
| 75 | Given the following test function: |
| 76 | |
| 77 | \begin{verbatim} |
| 78 | def testSomething(): |
| 79 | something = makeSomething() |
| 80 | assert something.name is not None |
| 81 | # ... |
| 82 | \end{verbatim} |
| 83 | |
| 84 | one can create an equivalent test case instance as follows: |
| 85 | |
| 86 | \begin{verbatim} |
| 87 | testcase = unittest.FunctionTestCase(testSomething) |
| 88 | \end{verbatim} |
| 89 | |
| 90 | If there are additional set-up and tear-down methods that should be |
| 91 | called as part of the test case's operation, they can also be provided: |
| 92 | |
| 93 | \begin{verbatim} |
| 94 | testcase = unittest.FunctionTestCase(testSomething, |
| 95 | setUp=makeSomethingDB, |
| 96 | tearDown=deleteSomethingDB) |
| 97 | \end{verbatim} |
| 98 | |
| 99 | |
| 100 | \subsection{Classes and functions |
| 101 | \label{unittest-contents}} |
| 102 | |
| 103 | \begin{classdesc}{TestCase}{} |
| 104 | Instances of the \class{TestCase} class represent the smallest |
| 105 | testable units in a set of tests. This class is intended to be used |
| 106 | as a base class, with specific tests being implemented by concrete |
| 107 | subclasses. This class implements the interface needed by the test |
| 108 | runner to allow it to drive the test, and methods that the test code |
| 109 | can use to check for and report various kinds of failures. |
| 110 | \end{classdesc} |
| 111 | |
| 112 | \begin{classdesc}{FunctionTestCase}{testFunc\optional{, |
| 113 | setup\optional{, tearDown\optional{, description}}}} |
| 114 | This class implements the portion of the \class{TestCase} interface |
| 115 | which allows the test runner to drive the test, but does not provide |
| 116 | the methods which test code can use to check and report errors. |
| 117 | This is used to create test cases using legacy test code, allowing |
| 118 | it to be integrated into a \refmodule{unittest}-based test |
| 119 | framework. |
| 120 | \end{classdesc} |
| 121 | |
| 122 | \begin{classdesc}{TestSuite}{} |
| 123 | This class represents an aggregation of individual tests cases and |
| 124 | test suites. The class presents the interface needed by the test |
| 125 | runner to allow it to be run as any other test case, but all the |
| 126 | contained tests and test suites are executed. Additional methods |
| 127 | are provided to add test cases and suites to the aggregation. |
| 128 | \end{classdesc} |
| 129 | |
| 130 | \begin{classdesc}{TestLoader}{} |
| 131 | \end{classdesc} |
| 132 | |
| 133 | \begin{classdesc}{TextTestRunner}{\optional{stream\optional{, |
| 134 | descriptions\optional{, verbosity}}}} |
| 135 | \end{classdesc} |
| 136 | |
| 137 | \begin{funcdesc}{main}{\optional{module\optional{, |
| 138 | defaultTest\optional{, argv\optional{, |
| 139 | testRunner\optional{, testRunner}}}}}} |
| 140 | A command-line program that runs a set of tests; this is primarily |
| 141 | for making test modules conveniently executable. The simplest use for |
| 142 | this function is: |
| 143 | |
| 144 | \begin{verbatim} |
| 145 | if __name__ == '__main__': |
| 146 | unittest.main() |
| 147 | \end{verbatim} |
| 148 | \end{funcdesc} |
| 149 | |
| 150 | |
| 151 | \subsection{TestCase Objects |
| 152 | \label{testcase-objects}} |
| 153 | |
| 154 | |
| 155 | \subsection{TestSuite Objects |
| 156 | \label{testsuite-objects}} |
| 157 | |
| 158 | \class{TestSuite} objects behave much like \class{TestCase} objects, |
| 159 | except they do not actually implement a test. Instead, they are used |
| 160 | to aggregate tests into groups that should be run together. Some |
| 161 | additional methods are available to add tests to \class{TestSuite} |
| 162 | instances: |
| 163 | |
| 164 | \begin{methoddesc}[TestSuite]{addTest}{test} |
| 165 | Add a \class{TestCase} or \class{TestSuite} to the set of tests that |
| 166 | make up the suite. |
| 167 | \end{methoddesc} |
| 168 | |
| 169 | \begin{methoddesc}[TestSuite]{addTests}{tests} |
| 170 | Add all the tests from a sequence of \class{TestCase} and |
| 171 | \class{TestSuite} instances to this test suite. |
| 172 | \end{methoddesc} |
| 173 | |
| 174 | |
| 175 | \subsection{TestResult Objects |
| 176 | \label{testresult-objects}} |
| 177 | |
| 178 | A \class{TestResult} object stores the results of a set of tests. The |
| 179 | \class{TestCase} and \class{TestSuite} classes ensure that results are |
| 180 | properly stored; test authors do not need to worry about recording the |
| 181 | outcome of tests. |
| 182 | |
| 183 | Testing frameworks built on top of \refmodule{unittest} may want |
| 184 | access to the \class{TestResult} object generated by running a set of |
| 185 | tests for reporting purposes; a \class{TestResult} instance is |
| 186 | returned by the \method{TestRunner.run()} method for this purpose. |
| 187 | |
| 188 | Each instance holds the total number of tests run, and collections of |
| 189 | failures and errors that occurred among those test runs. The |
| 190 | collections contain tuples of \code{(\var{testcase}, |
| 191 | \var{exceptioninfo})}, where \var{exceptioninfo} is a tuple as |
| 192 | returned by \function{sys.exc_info()}. |
| 193 | |
| 194 | \class{TestResult} instances have the following attributes that will |
| 195 | be of interest when inspecting the results of running a set of tests: |
| 196 | |
| 197 | \begin{memberdesc}[TestResult]{errors} |
| 198 | A list containing pairs of \class{TestCase} instances and the |
| 199 | \function{sys.exc_info()} results for tests which raised exceptions |
| 200 | other than \exception{AssertionError}. |
| 201 | \end{memberdesc} |
| 202 | |
| 203 | \begin{memberdesc}[TestResult]{failures} |
| 204 | A list containing pairs of \class{TestCase} instances and the |
| 205 | \function{sys.exc_info()} results for tests which raised the |
| 206 | \exception{AssertionError} exception. |
| 207 | \end{memberdesc} |
| 208 | |
| 209 | \begin{memberdesc}[TestResult]{testsRun} |
| 210 | The number of tests which have been started. |
| 211 | \end{memberdesc} |
| 212 | |
| 213 | \begin{methoddesc}[TestResult]{wasSuccessful}{} |
| 214 | Returns true if all tests run so far have passed, otherwise returns |
| 215 | false. |
| 216 | \end{methoddesc} |
| 217 | |
| 218 | |
| 219 | The following methods of the \class{TestResult} class are used to |
| 220 | maintain the internal data structures, and mmay be extended in |
| 221 | subclasses to support additional reporting requirements. This is |
| 222 | particularly useful in building GUI tools which support interactive |
| 223 | reporting while tests are being run. |
| 224 | |
| 225 | \begin{methoddesc}[TestResult]{startTest}{test} |
| 226 | Called when the test case \var{test} is about to be run. |
| 227 | \end{methoddesc} |
| 228 | |
| 229 | \begin{methoddesc}[TestResult]{stopTest}{test} |
| 230 | Called when the test case \var{test} has been executed, regardless |
| 231 | of the outcome. |
| 232 | \end{methoddesc} |
| 233 | |
| 234 | \begin{methoddesc}[TestResult]{addError}{test, err} |
| 235 | Called when the test case \var{test} results in an exception other |
| 236 | than \exception{AssertionError}. \var{err} is a tuple of the form |
| 237 | returned by \function{sys.exc_info()}: \code{(\var{type}, |
| 238 | \var{value}, \var{traceback})}. |
| 239 | \end{methoddesc} |
| 240 | |
| 241 | \begin{methoddesc}[TestResult]{addFailure}{test, err} |
| 242 | Called when the test case \var{test} results in an |
| 243 | \exception{AssertionError} exception; the assumption is that the |
| 244 | test raised the \exception{AssertionError} and not the |
| 245 | implementation being tested. \var{err} is a tuple of the form |
| 246 | returned by \function{sys.exc_info()}: \code{(\var{type}, |
| 247 | \var{value}, \var{traceback})}. |
| 248 | \end{methoddesc} |
| 249 | |
| 250 | \begin{methoddesc}[TestResult]{addSuccess}{test} |
| 251 | This method is called for a test that does not fail; \var{test} is |
| 252 | the test case object. |
| 253 | \end{methoddesc} |
| 254 | |
| 255 | |
| 256 | One additional method is available for \class{TestResult} objects: |
| 257 | |
| 258 | \begin{methoddesc}[TestResult]{stop}{} |
| 259 | This method can be called to signal that the set of tests being run |
| 260 | should be aborted. Once this has been called, the |
| 261 | \class{TestRunner} object return to its caller without running any |
| 262 | additional tests. This is used by the \class{TextTestRunner} class |
| 263 | to stop the test framework when the user signals an interrupt from |
| 264 | the keyboard. GUI tools which provide runners can use this in a |
| 265 | similar manner. |
| 266 | \end{methoddesc} |