-
-
Notifications
You must be signed in to change notification settings - Fork 3.1k
Option for pytest.fail to not print exception context #11457
Copy link
Copy link
Open
Labels
topic: reportingrelated to terminal output and user-facing messages and errorsrelated to terminal output and user-facing messages and errorstype: proposalproposal for a new feature, often to gather opinions or design the API around the new featureproposal for a new feature, often to gather opinions or design the API around the new feature
Metadata
Metadata
Assignees
Labels
topic: reportingrelated to terminal output and user-facing messages and errorsrelated to terminal output and user-facing messages and errorstype: proposalproposal for a new feature, often to gather opinions or design the API around the new featureproposal for a new feature, often to gather opinions or design the API around the new feature
Type
Fields
Give feedbackNo fields configured for issues without a type.
Context
Currently, one of the ways to use
pytest.failis to include all of the necessary information in thereasonfield and disabling the traceback withpytrace = False. While this does suppress tracebacks of the exception itself and any exceptions in the context, it still prints the context. I use this in python-trio/pytest-trio#136 for example to report full tracebacks when a timeout happens (capturing all async tasks). Currently, this implementation prints the set of tracebacks twice as an internal exception (which also contains the tracebacks) is converted to a test failure withpytest.fail.Feature request
I would like to have a way to suppress this context as well, either by default if
pytrace = Falseis set, or with another option. This is the behavior I would have expected frompytracein the first place.Alternatives
It is possible to do some juggling with the exceptions to remove the context as follows:
I think this would be reasonable to implement in a plugin for example, but might be a bit to cumbersome/obscure for use in tests. But that is not where my use case lies, so this might a case of the XY problem. Another solution would be to use a report hook to customize the reporting of certain special exceptions.
It might be that these alternatives are acceptable (I presume that this case is not a common occurrence) and adding this feature is not worth the maintenance/testing/change in behavior. But I believe it is still worth considering at least.