-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
@pytest.mark.xfail has no option to raise all Exceptions #8665
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
Comments
On MWE 3:
So I assumed an empty list was also allowed. Related to #8646? |
A failing assertion is an exception as well (an Agreed that |
Can you link to the docs you're referencing? Because at https://docs.pytest.org/en/latest/how-to/skipping.html#raises-parameter I see:
and I would expect passing a list to be an error, since you can't pass it to IMO passing an empty sequence of exceptions should be an explicit error, though of course via a deprecation period if the current behaviour is to silently ignore the argument. |
Yes! Thank you :) That solves the immediate problem I needed. @Zac-HD, @pytest.mark.xfail(raises=()) only allows a test to XPASS or FAIL, without possibility of XFAIL. This is perhaps a bit less jarring than silently ignoring the argument. Now that I'm reading the correct docs, 🤦♂️, I'm personally fine with the current behavior. So I guess there's three questions at play:
|
|
pip list
from the virtual environment you are usingDesired/Expected behavior
I'm looking to XFAIL a test, but only at an
assert False
and not for anyException
. I would like exceptions to be reported as ERRORs and not XFAILs. I opened this as a bug report because its unclear to me whether such behavior should exist with@pytest.mark.xfail(raises=[])
(currently raises an internal error in pytest, see MWE 3), or whether the desired behavior is a feature request.In addition, I'm unclear whether the right behavior with
@pytest.mark.xfail(raises=None)
should differ between anException
in the test (see MWE 1) versus anException
in the test setup (see MWE 2). @RonnyPfannschmidt's comment on #5044 seems to indicate tests marked xfail should ERROR instead of XFAIL when theException
occurs in setup code:Rationale:
I added an integration test for an app's workflow. Because I'm still creating low-level fixtures that are not yet deterministic, I am not sure what the expected output of the integration test should be. However, the test should still be able to run without errors. I understand that the test could be written:
Then later, I could populate
expected
with the correct fixture and change the name of the test. The test and coverage report seems clearer, however, to have a test with an XFAIL mark. It would be removed when I write the correct fixture and can determine the expected output.MWEs
Case 1 is an
Exception
in the test, case 2 is anException
in test setup. In both cases, the test runs as an XFAIL rather than an ERROR. Case 3 includes the expected calling signature, along with the traceback.Case 1
Case 2
Case 3:
Case 3 traceback
Versions
pip list
The text was updated successfully, but these errors were encountered: