-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Labels
bug
Something isn't working
Comments
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 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
Environment
What is happening?
If you use the
unittest.expectedFailure
decorator on a test in aQiskitTestCase
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
:The output of
unittest
is something like: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 intoFullQiskitTestCase
, or maybe eventesttools
itself.The text was updated successfully, but these errors were encountered: