Skip to content
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

Tests do not respect unittest.expectedFailure #7307

Closed
jakelishman opened this issue Nov 24, 2021 · 0 comments · Fixed by #7311
Closed

Tests do not respect unittest.expectedFailure #7307

jakelishman opened this issue Nov 24, 2021 · 0 comments · Fixed by #7311
Labels
bug Something isn't working

Comments

@jakelishman
Copy link
Member

Environment

  • Qiskit Terra version: 0.19.0.dev0 @ f6ab3a9
  • Python version: any
  • Operating system: any

What is happening?

If you use the unittest.expectedFailure decorator on a test in a QiskitTestCase class, the test just reports a regular failure rather than a correct xfail.

How can we reproduce the issue?

This is a sample test file test_failures.py:

import unittest
import qiskit.test.base

class Direct(unittest.TestCase):
    @unittest.expectedFailure
    def test_failure(self):
        self.assertTrue(False)

class Base(qiskit.test.base.BaseQiskitTestCase):
    @unittest.expectedFailure
    def test_failure(self):
        self.assertTrue(False)

class Full(qiskit.test.base.FullQiskitTestCase):
    @unittest.expectedFailure
    def test_failure(self):
        self.assertTrue(False)

The output of unittest is something like:

xxF
======================================================================
FAIL: test_failure (test_failures.Full)
----------------------------------------------------------------------
testtools.testresult.real._StringException: Traceback (most recent call last):
  File "/Users/jake/code/qiskit/terra/test_failures.py", line 20, in test_failure
    self.assertTrue(False)
  File "/Users/jake/.miniconda3/envs/qiskit/lib/python3.9/unittest/case.py", line 682, in assertTrue
    raise self.failureException(msg)
AssertionError: False is not true


----------------------------------------------------------------------
Ran 3 tests in 0.005s

FAILED (failures=1, expected failures=2)

What should happen?

The test in the FullQiskitTestCase should also report an expected failure.

Any suggestions?

Likely related to some of the testtools code we've imported into FullQiskitTestCase, or maybe even testtools itself.

@jakelishman jakelishman added the bug Something isn't working label Nov 24, 2021
mtreinish added a commit to mtreinish/qiskit-core that referenced this issue Nov 24, 2021
In Qiskit#3982 we forked a bunch of internals around results handling and
attachments from the testtools library to enable better stdout, stderr,
and pylogging handling when running with stestr (which is our default
runner in CI). This was necessary at the time because testtools relied
on unittest2 (which was a rolling backport package from unittest to
bring new features from newer python's unittest to older python
versions) that has gone unmaintained for years and was causing
incompatibilities with stdlib unittest on newer python versions. However
as of the testtools 2.5.0 release it no longer depends on unittest2 and
instead inherits directly from unittest fixing the compatibility issues
we were facing previously. This means our fork of the result and
attachment handling from testtools is no longer necessary and we can
just use their TestCase. However, since we do not want to require the
use of testtools outside of running with stestr this commit retains the
same spit logic around when we use it to ensure that we're only
opportunistically using the library if it's installed. This enables
people to no have testtools (which honestly isn't the best maintained
library anymore) taint their code path unless it's already installed.

Fixes Qiskit#7307
@mergify mergify bot closed this as completed in #7311 Nov 24, 2021
mergify bot pushed a commit that referenced this issue Nov 24, 2021
In #3982 we forked a bunch of internals around results handling and
attachments from the testtools library to enable better stdout, stderr,
and pylogging handling when running with stestr (which is our default
runner in CI). This was necessary at the time because testtools relied
on unittest2 (which was a rolling backport package from unittest to
bring new features from newer python's unittest to older python
versions) that has gone unmaintained for years and was causing
incompatibilities with stdlib unittest on newer python versions. However
as of the testtools 2.5.0 release it no longer depends on unittest2 and
instead inherits directly from unittest fixing the compatibility issues
we were facing previously. This means our fork of the result and
attachment handling from testtools is no longer necessary and we can
just use their TestCase. However, since we do not want to require the
use of testtools outside of running with stestr this commit retains the
same spit logic around when we use it to ensure that we're only
opportunistically using the library if it's installed. This enables
people to no have testtools (which honestly isn't the best maintained
library anymore) taint their code path unless it's already installed.

Fixes #7307
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant