Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 1 | |
| 2 | :mod:`test` --- Regression tests package for Python |
| 3 | =================================================== |
| 4 | |
| 5 | .. module:: test |
| 6 | :synopsis: Regression tests package containing the testing suite for Python. |
| 7 | .. sectionauthor:: Brett Cannon <brett@python.org> |
| 8 | |
| 9 | |
| 10 | The :mod:`test` package contains all regression tests for Python as well as the |
| 11 | modules :mod:`test.test_support` and :mod:`test.regrtest`. |
| 12 | :mod:`test.test_support` is used to enhance your tests while |
| 13 | :mod:`test.regrtest` drives the testing suite. |
| 14 | |
| 15 | Each module in the :mod:`test` package whose name starts with ``test_`` is a |
| 16 | testing suite for a specific module or feature. All new tests should be written |
| 17 | using the :mod:`unittest` or :mod:`doctest` module. Some older tests are |
| 18 | written using a "traditional" testing style that compares output printed to |
| 19 | ``sys.stdout``; this style of test is considered deprecated. |
| 20 | |
| 21 | |
| 22 | .. seealso:: |
| 23 | |
| 24 | Module :mod:`unittest` |
| 25 | Writing PyUnit regression tests. |
| 26 | |
| 27 | Module :mod:`doctest` |
| 28 | Tests embedded in documentation strings. |
| 29 | |
| 30 | |
| 31 | .. _writing-tests: |
| 32 | |
| 33 | Writing Unit Tests for the :mod:`test` package |
| 34 | ---------------------------------------------- |
| 35 | |
| 36 | .. % |
| 37 | |
| 38 | It is preferred that tests that use the :mod:`unittest` module follow a few |
| 39 | guidelines. One is to name the test module by starting it with ``test_`` and end |
| 40 | it with the name of the module being tested. The test methods in the test module |
| 41 | should start with ``test_`` and end with a description of what the method is |
| 42 | testing. This is needed so that the methods are recognized by the test driver as |
| 43 | test methods. Also, no documentation string for the method should be included. A |
| 44 | comment (such as ``# Tests function returns only True or False``) should be used |
| 45 | to provide documentation for test methods. This is done because documentation |
| 46 | strings get printed out if they exist and thus what test is being run is not |
| 47 | stated. |
| 48 | |
| 49 | A basic boilerplate is often used:: |
| 50 | |
| 51 | import unittest |
| 52 | from test import test_support |
| 53 | |
| 54 | class MyTestCase1(unittest.TestCase): |
| 55 | |
| 56 | # Only use setUp() and tearDown() if necessary |
| 57 | |
| 58 | def setUp(self): |
| 59 | ... code to execute in preparation for tests ... |
| 60 | |
| 61 | def tearDown(self): |
| 62 | ... code to execute to clean up after tests ... |
| 63 | |
| 64 | def test_feature_one(self): |
| 65 | # Test feature one. |
| 66 | ... testing code ... |
| 67 | |
| 68 | def test_feature_two(self): |
| 69 | # Test feature two. |
| 70 | ... testing code ... |
| 71 | |
| 72 | ... more test methods ... |
| 73 | |
| 74 | class MyTestCase2(unittest.TestCase): |
| 75 | ... same structure as MyTestCase1 ... |
| 76 | |
| 77 | ... more test classes ... |
| 78 | |
| 79 | def test_main(): |
| 80 | test_support.run_unittest(MyTestCase1, |
| 81 | MyTestCase2, |
| 82 | ... list other tests ... |
| 83 | ) |
| 84 | |
| 85 | if __name__ == '__main__': |
| 86 | test_main() |
| 87 | |
| 88 | This boilerplate code allows the testing suite to be run by :mod:`test.regrtest` |
| 89 | as well as on its own as a script. |
| 90 | |
| 91 | The goal for regression testing is to try to break code. This leads to a few |
| 92 | guidelines to be followed: |
| 93 | |
| 94 | * The testing suite should exercise all classes, functions, and constants. This |
| 95 | includes not just the external API that is to be presented to the outside world |
| 96 | but also "private" code. |
| 97 | |
| 98 | * Whitebox testing (examining the code being tested when the tests are being |
| 99 | written) is preferred. Blackbox testing (testing only the published user |
| 100 | interface) is not complete enough to make sure all boundary and edge cases are |
| 101 | tested. |
| 102 | |
| 103 | * Make sure all possible values are tested including invalid ones. This makes |
| 104 | sure that not only all valid values are acceptable but also that improper values |
| 105 | are handled correctly. |
| 106 | |
| 107 | * Exhaust as many code paths as possible. Test where branching occurs and thus |
| 108 | tailor input to make sure as many different paths through the code are taken. |
| 109 | |
| 110 | * Add an explicit test for any bugs discovered for the tested code. This will |
| 111 | make sure that the error does not crop up again if the code is changed in the |
| 112 | future. |
| 113 | |
| 114 | * Make sure to clean up after your tests (such as close and remove all temporary |
| 115 | files). |
| 116 | |
| 117 | * If a test is dependent on a specific condition of the operating system then |
| 118 | verify the condition already exists before attempting the test. |
| 119 | |
| 120 | * Import as few modules as possible and do it as soon as possible. This |
| 121 | minimizes external dependencies of tests and also minimizes possible anomalous |
| 122 | behavior from side-effects of importing a module. |
| 123 | |
| 124 | * Try to maximize code reuse. On occasion, tests will vary by something as small |
| 125 | as what type of input is used. Minimize code duplication by subclassing a basic |
| 126 | test class with a class that specifies the input:: |
| 127 | |
| 128 | class TestFuncAcceptsSequences(unittest.TestCase): |
| 129 | |
| 130 | func = mySuperWhammyFunction |
| 131 | |
| 132 | def test_func(self): |
| 133 | self.func(self.arg) |
| 134 | |
| 135 | class AcceptLists(TestFuncAcceptsSequences): |
| 136 | arg = [1,2,3] |
| 137 | |
| 138 | class AcceptStrings(TestFuncAcceptsSequences): |
| 139 | arg = 'abc' |
| 140 | |
| 141 | class AcceptTuples(TestFuncAcceptsSequences): |
| 142 | arg = (1,2,3) |
| 143 | |
| 144 | |
| 145 | .. seealso:: |
| 146 | |
| 147 | Test Driven Development |
| 148 | A book by Kent Beck on writing tests before code. |
| 149 | |
| 150 | |
| 151 | .. _regrtest: |
| 152 | |
| 153 | Running tests using :mod:`test.regrtest` |
| 154 | ---------------------------------------- |
| 155 | |
| 156 | :mod:`test.regrtest` can be used as a script to drive Python's regression test |
| 157 | suite. Running the script by itself automatically starts running all regression |
| 158 | tests in the :mod:`test` package. It does this by finding all modules in the |
| 159 | package whose name starts with ``test_``, importing them, and executing the |
| 160 | function :func:`test_main` if present. The names of tests to execute may also be |
| 161 | passed to the script. Specifying a single regression test (:program:`python |
| 162 | regrtest.py` :option:`test_spam.py`) will minimize output and only print whether |
| 163 | the test passed or failed and thus minimize output. |
| 164 | |
| 165 | Running :mod:`test.regrtest` directly allows what resources are available for |
| 166 | tests to use to be set. You do this by using the :option:`-u` command-line |
| 167 | option. Run :program:`python regrtest.py` :option:`-uall` to turn on all |
| 168 | resources; specifying :option:`all` as an option for :option:`-u` enables all |
| 169 | possible resources. If all but one resource is desired (a more common case), a |
| 170 | comma-separated list of resources that are not desired may be listed after |
| 171 | :option:`all`. The command :program:`python regrtest.py` |
| 172 | :option:`-uall,-audio,-largefile` will run :mod:`test.regrtest` with all |
| 173 | resources except the :option:`audio` and :option:`largefile` resources. For a |
| 174 | list of all resources and more command-line options, run :program:`python |
| 175 | regrtest.py` :option:`-h`. |
| 176 | |
| 177 | Some other ways to execute the regression tests depend on what platform the |
| 178 | tests are being executed on. On Unix, you can run :program:`make` :option:`test` |
| 179 | at the top-level directory where Python was built. On Windows, executing |
| 180 | :program:`rt.bat` from your :file:`PCBuild` directory will run all regression |
| 181 | tests. |
| 182 | |
| 183 | |
| 184 | :mod:`test.test_support` --- Utility functions for tests |
| 185 | ======================================================== |
| 186 | |
| 187 | .. module:: test.test_support |
| 188 | :synopsis: Support for Python regression tests. |
| 189 | |
| 190 | |
| 191 | The :mod:`test.test_support` module provides support for Python's regression |
| 192 | tests. |
| 193 | |
| 194 | This module defines the following exceptions: |
| 195 | |
| 196 | |
| 197 | .. exception:: TestFailed |
| 198 | |
| 199 | Exception to be raised when a test fails. This is deprecated in favor of |
| 200 | :mod:`unittest`\ -based tests and :class:`unittest.TestCase`'s assertion |
| 201 | methods. |
| 202 | |
| 203 | |
| 204 | .. exception:: TestSkipped |
| 205 | |
| 206 | Subclass of :exc:`TestFailed`. Raised when a test is skipped. This occurs when a |
| 207 | needed resource (such as a network connection) is not available at the time of |
| 208 | testing. |
| 209 | |
| 210 | |
| 211 | .. exception:: ResourceDenied |
| 212 | |
| 213 | Subclass of :exc:`TestSkipped`. Raised when a resource (such as a network |
| 214 | connection) is not available. Raised by the :func:`requires` function. |
| 215 | |
| 216 | The :mod:`test.test_support` module defines the following constants: |
| 217 | |
| 218 | |
| 219 | .. data:: verbose |
| 220 | |
| 221 | :const:`True` when verbose output is enabled. Should be checked when more |
| 222 | detailed information is desired about a running test. *verbose* is set by |
| 223 | :mod:`test.regrtest`. |
| 224 | |
| 225 | |
| 226 | .. data:: have_unicode |
| 227 | |
| 228 | :const:`True` when Unicode support is available. |
| 229 | |
| 230 | |
| 231 | .. data:: is_jython |
| 232 | |
| 233 | :const:`True` if the running interpreter is Jython. |
| 234 | |
| 235 | |
| 236 | .. data:: TESTFN |
| 237 | |
| 238 | Set to the path that a temporary file may be created at. Any temporary that is |
| 239 | created should be closed and unlinked (removed). |
| 240 | |
| 241 | The :mod:`test.test_support` module defines the following functions: |
| 242 | |
| 243 | |
| 244 | .. function:: forget(module_name) |
| 245 | |
| 246 | Removes the module named *module_name* from ``sys.modules`` and deletes any |
| 247 | byte-compiled files of the module. |
| 248 | |
| 249 | |
| 250 | .. function:: is_resource_enabled(resource) |
| 251 | |
| 252 | Returns :const:`True` if *resource* is enabled and available. The list of |
| 253 | available resources is only set when :mod:`test.regrtest` is executing the |
| 254 | tests. |
| 255 | |
| 256 | |
| 257 | .. function:: requires(resource[, msg]) |
| 258 | |
| 259 | Raises :exc:`ResourceDenied` if *resource* is not available. *msg* is the |
| 260 | argument to :exc:`ResourceDenied` if it is raised. Always returns true if called |
| 261 | by a function whose ``__name__`` is ``'__main__'``. Used when tests are executed |
| 262 | by :mod:`test.regrtest`. |
| 263 | |
| 264 | |
| 265 | .. function:: findfile(filename) |
| 266 | |
| 267 | Return the path to the file named *filename*. If no match is found *filename* is |
| 268 | returned. This does not equal a failure since it could be the path to the file. |
| 269 | |
| 270 | |
| 271 | .. function:: run_unittest(*classes) |
| 272 | |
| 273 | Execute :class:`unittest.TestCase` subclasses passed to the function. The |
| 274 | function scans the classes for methods starting with the prefix ``test_`` and |
| 275 | executes the tests individually. |
| 276 | |
| 277 | It is also legal to pass strings as parameters; these should be keys in |
| 278 | ``sys.modules``. Each associated module will be scanned by |
| 279 | ``unittest.TestLoader.loadTestsFromModule()``. This is usually seen in the |
| 280 | following :func:`test_main` function:: |
| 281 | |
| 282 | def test_main(): |
| 283 | test_support.run_unittest(__name__) |
| 284 | |
| 285 | This will run all tests defined in the named module. |
| 286 | |
| 287 | The :mod:`test.test_support` module defines the following classes: |
| 288 | |
| 289 | |
| 290 | .. class:: TransientResource(exc[, **kwargs]) |
| 291 | |
| 292 | Instances are a context manager that raises :exc:`ResourceDenied` if the |
| 293 | specified exception type is raised. Any keyword arguments are treated as |
| 294 | attribute/value pairs to be compared against any exception raised within the |
| 295 | :keyword:`with` statement. Only if all pairs match properly against |
| 296 | attributes on the exception is :exc:`ResourceDenied` raised. |
| 297 | |
| 298 | .. versionadded:: 2.6 |
| 299 | |
| 300 | |
| 301 | .. class:: EnvironmentVarGuard() |
| 302 | |
| 303 | Class used to temporarily set or unset environment variables. Instances can be |
| 304 | used as a context manager. |
| 305 | |
| 306 | .. versionadded:: 2.6 |
| 307 | |
| 308 | |
| 309 | .. method:: EnvironmentVarGuard.set(envvar, value) |
| 310 | |
| 311 | Temporarily set the environment variable ``envvar`` to the value of ``value``. |
| 312 | |
| 313 | |
| 314 | .. method:: EnvironmentVarGuard.unset(envvar) |
| 315 | |
| 316 | Temporarily unset the environment variable ``envvar``. |
| 317 | |