-
-
Couldn't load subscription status.
- Fork 33.3k
gh-80793: Edit unittest.rst on SetUpClass calls #12798
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -2309,17 +2309,20 @@ Class and Module Fixtures | |
| ------------------------- | ||
|
|
||
| Class and module level fixtures are implemented in :class:`TestSuite`. When | ||
| the test suite encounters a test from a new class then :meth:`tearDownClass` | ||
| from the previous class (if there is one) is called, followed by | ||
| the test suite encounters a test that is from a different class from the previous | ||
| test, then :meth:`tearDownClass` from the previous class is called, followed by | ||
| :meth:`setUpClass` from the new class. | ||
|
|
||
| Similarly if a test is from a different module from the previous test then | ||
| ``tearDownModule`` from the previous module is run, followed by | ||
| Similarly if a test is from a different module from the previous test, then | ||
| ``tearDownModule`` from the previous module is called, followed by | ||
| ``setUpModule`` from the new module. | ||
|
|
||
| After all the tests have run the final ``tearDownClass`` and | ||
| ``tearDownModule`` are run. | ||
|
|
||
| The abovementioned calls are only executed, | ||
| if the corresponding method or function is found. | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Choosing "method is found", instead of "method exists" or "class has a method", in order to hint method resolution order is in effect. |
||
|
|
||
| Note that shared fixtures do not play well with [potential] features like test | ||
| parallelization and they break test isolation. They should be used with care. | ||
|
|
||
|
|
@@ -2358,9 +2361,10 @@ These must be implemented as class methods:: | |
| def tearDownClass(cls): | ||
| cls._connection.destroy() | ||
|
|
||
| If you want the ``setUpClass`` and ``tearDownClass`` on base classes called | ||
| then you must call up to them yourself. The implementations in | ||
| :class:`TestCase` are empty. | ||
| The implementations in :class:`TestCase` are present, but empty. | ||
|
||
| That means the implemenation is executed for classes descending from | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Choosing "descending" instead of "derived" or "child", to suggest the inheritance graphs can be complicated. |
||
| :class:`TestCase`, but the implementation does not do anything, | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Empty implementation executed means no special handling is there to interfere with normal inheritance rules. |
||
| unless overriden as in the example. | ||
|
|
||
| If an exception is raised during a ``setUpClass`` then the tests in the class | ||
| are not run and the ``tearDownClass`` is not run. Skipped classes will not | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why removing the "if there is one"? It was right:
I don't see any problem with this paragraph, and it looks not correlated with bpo-36612.