-
-
Notifications
You must be signed in to change notification settings - Fork 29.9k
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
"unittest.TestCase.debug" should honour "skip" (and other test controls) #80855
Comments
Currently, "TestCase.run" supports several features to control testing - among others, a test can be skipped via the attribute "__unittest_skip__". "TestCase.debug" ignores all those controls and calls the test method unconditionally. I am using "zope.testrunner" to run test suites. Its "-D" option switches from "TestCase.run" to "TestCase.debug" in order to allow the analysis of the state of a failing test in the Python debugger. "-D" is typically used if a test in a larger suite failed and a detailed analysis is required to determine the failure's cause. It is important that this second run executes the same tests as the first run; it is not helpful when the second run fails in a test skipped in the first run. Therefore, "TestCase.debug" should honour all test controls supported by "TestCase.run". One could argue that the testsuite runner should implement this logic. However, this would force the runner to duplicate the test control logic using internal implementation details of "unittest". Conceptually, it is much nicer to have the test control encapsulated by "unittest". |
3.6 only gets security fixes. This appears to be an enhancement request. SkipTest is an exception and according to the doc it should be propagated to the caller. __unittest_skip__ is an undocumented internal name, so you probably should not be using it. If this request is not rejected, we will need test code demonstrating the issue *that does not use zope*. |
Terry J. Reedy wrote:
The "skip" I am speaking about is a decorator for tests or test classes telling a "runner" to skip tests (likely because conditions for their success are not met - usually, that required packages are not installed). This "skip" (decorator) uses The "unittest runner" is extremely rudimentary and lacks many important features. That is why I use the much more feature rich I attach a test script - which likely is not convincing as the feature is mainly important for a sophisticated test runner, not for explicit calls of |
+1, I think tests should run the same way in debug() and run(), the difference being limited only to how the result is handled. Marking a test as skipped should still be skipped while debugging, else it pollutes the results with tests that will not run with run(). |
from unittest import TestCase, skipIf
#@skipIf(True, "Skip Testing")
class Tests(TestCase):
def test_skip(self):
"this test will fail - if not skipped"
print('asserting')
self.assertEqual(0, 1) print(Tests("test_skip").run()) test_skip is run twice, with the output difference being as documented. asserting
<unittest.result.TestResult run=1 errors=0 failures=1>
asserting
Traceback (most recent call last):
...
AssertionError: 0 != 1
print(Tests("test_skip").run().skipped) results in the output I expect from the doc. <unittest.result.TestResult run=1 errors=0 failures=0>
[(<__main__.Tests testMethod=test_skip>, 'why')]
Traceback (most recent call last):
...
unittest.case.SkipTest: why
None Since .run does not run the test, I agree that debug() running the test and raising AssertionError is a bug. The test should not be run. In my original comments, I expected SkipTest, as in cases 2 above and 4 below. I have not yet checked the current tests. 4. SKIPIF FUNC Moving the skipIf decorator to test_skip results in
None
Traceback (most recent call last):
..
unittest.case.SkipTest: Skip Testing I don't know why run() returns None for skipIf cases instead of returning a TestResult with non-empty skipped, as it does for skipTest, or if the None is a separate bug. |
"I don't know why run() returns None for skipIf cases instead of returning a TestResult with non-empty skipped, as it does for skipTest, or if the None is a separate bug." That does sound like a bug. |
See bpo-41620 for run() returning None. |
There are too many issues with TestResult.debug(). It does not call tearDown() and doCleanups() if the test is skipped, failed or raises other exception (including errors in cleanup). It does not support skipping decorators. It does not support the expectedFailure decorator. It does not work at all in IsolatedAsyncioTestCase. |
PR 28446 makes TestCase.debug() honoring the skipping decorator. The difference with PR 13180:
|
Since the behavior of debug() was different for the following cases:
I consider it as a bug and will backport the fix. |
See bpo-45238 for debug() in IsolatedAsyncioTestCase. |
Thank you for working on this issue! |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: