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:

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*.

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 __unittest_skip__ to tell the the "unittest runner" (that is unittest.TestCase.run) that the test should be skipped.

The "unittest runner" is extremely rudimentary and lacks many important features. That is why I use the much more feature rich zope.testrunner. I could implement the __unittest_skip__ logic there - but as you wrote - this should remain encapsulated inside unittest (that's why I wrote this issue).

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 TestCase.debug.

+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().

1. NO SKIP utest.py with debug prints added and @skipIf initially commented out.
   ---

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())
print(Tests("test_skip").debug())
---

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

2. SKIPTEST Adding "self.skipTest('why')" either in a new setUp() or at the top of skip_test() and adding another print

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

3. SKIPIF CLASS Uncommenting @skipIf (the OP's case) instead results in

None
asserting
Traceback ...
AssertionError: 0 != 1

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:

1. It does not run setUp() and tearDown() for tests decorated with the skipping decorator, as TestCase.run().
2. It has the same behavior for tests decorated with the skipping decorator and tests using skipTest() or raising a SkipTest -- raises a SkipTest.
3. Tests actually test the skipping decorator.

Since the behavior of debug() was different for the following cases:

@skip('skipping')
def test1(self):
    pass
@othedecorator
@skip('skipping')
def test2(self):
    pass
def test3(self):
    self.skipTest('skipping')

I consider it as a bug and will backport the fix.

New changeset dea59cf by Serhiy Storchaka in branch 'main':
bpo-36674: Honour the skipping decorators in TestCase.debug() (GH-28446)
dea59cf

New changeset 753f7af by Miss Islington (bot) in branch '3.10':
bpo-36674: Honour the skipping decorators in TestCase.debug() (GH-28446)
753f7af

New changeset 7e465a6 by Miss Islington (bot) in branch '3.9':
bpo-36674: Honour the skipping decorators in TestCase.debug() (GH-28446)
7e465a6

See bpo-45238 for debug() in IsolatedAsyncioTestCase.

Thank you for working on this issue!