@@ -95,40 +95,6 @@ need to derive from a specific class.
9595 A special-interest-group for discussion of testing, and testing tools,
9696 in Python.
9797
98- .. _unittest-test-discovery :
99-
100- Test Discovery
101- --------------
102-
103- .. versionadded :: 3.2
104-
105- unittest supports simple test discovery. For a project's tests to be
106- compatible with test discovery they must all be importable from the top level
107- directory of the project; i.e. they must all be in Python packages.
108-
109- Test discovery is implemented in :meth: `TestLoader.discover `, but can also be
110- used from the command line. The basic command line usage is::
111-
112- cd project_directory
113- python -m unittest discover
114-
115- The ``discover `` sub-command has the following options:
116-
117- -v, --verbose Verbose output
118- -s directory Directory to start discovery ('.' default)
119- -p pattern Pattern to match test files ('test*.py' default)
120- -t directory Top level directory of project (default to
121- start directory)
122-
123- The -s, -p, & -t options can be passsed in as positional arguments. The
124- following two command lines are equivalent::
125-
126- python -m unittest discover -s project_directory -p '*_test.py'
127- python -m unittest discover project_directory '*_test.py'
128-
129- Test modules and packages can customize test loading and discovery by through
130- the `load_tests protocol `_.
131-
13298.. _unittest-minimal-example :
13399
134100Basic example
@@ -1904,8 +1870,17 @@ allow the currently running test to complete, and the test run will then end
19041870and report all the results so far. A second control-c will raise a
19051871``KeyboardInterrupt `` in the usual way.
19061872
1907- There are a few utility functions for framework authors to enable this
1908- functionality within test frameworks.
1873+ The control-c handling signal handler attempts to remain compatible with code or
1874+ tests that install their own :const: `signal.SIGINT ` handler. If the ``unittest ``
1875+ handler is called but *isn't * the installed :const: `signal.SIGINT ` handler,
1876+ i.e. it has been replaced by the system under test and delegated to, then it
1877+ calls the default handler. This will normally be the expected behavior by code
1878+ that replaces an installed handler and delegates to it. For individual tests
1879+ that need ``unittest `` control-c handling disabled the :func: `removeHandler `
1880+ decorator can be used.
1881+
1882+ There are a few utility functions for framework authors to enable control-c
1883+ handling functionality within test frameworks.
19091884
19101885.. function :: installHandler()
19111886
@@ -1919,9 +1894,23 @@ functionality within test frameworks.
19191894 result stores a weak reference to it, so it doesn't prevent the result from
19201895 being garbage collected.
19211896
1897+ Registering a :class: `TestResult ` object has no side-effects if control-c
1898+ handling is not enabled, so test frameworks can unconditionally register
1899+ all results they create independently of whether or not handling is enabled.
1900+
19221901.. function :: removeResult(result)
19231902
19241903 Remove a registered result. Once a result has been removed then
19251904 :meth: `~TestResult.stop ` will no longer be called on that result object in
19261905 response to a control-c.
19271906
1907+ .. function :: removeHandler(function=None)
1908+
1909+ When called without arguments this function removes the control-c handler
1910+ if it has been installed. This function can also be used as a test decorator
1911+ to temporarily remove the handler whilst the test is being executed::
1912+
1913+ @unittest.removeHandler
1914+ def test_signal_handling(self):
1915+ ...
1916+
0 commit comments