You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When executing pytester.runpytest in an environment containing a pytest plugin that modifies the output, the result is that vanilla pytester tries and fails to parse the modified output, yielding failed assert_outcomes.
For example, the following test suite, in an environment with pytest-pretty installed:
One additional factor here is that diagnosing this incompatibility is difficult -- none of the plugins involved advertise this incompatibility, and the code itself doesn't suggest anything might be wrong.
Several mitigations suggest themselves, in increasing order of complexity and safety:
Document prominently in the pytester documentation that it is incompatible with any plugin that modifies pytest's output
Standardize an interface for overriding the output to ensure that any fixture that calls runpytest will have a coherent set of bindings. eg enable explicitly setting which reporter pytest uses for its reporting, and then have runpytest explicitly but overridably set the reporter (so it's always parsing the report with the reporter it was expecting to be using)
Give pytest a way to emit a machine-readable version of the log, so it's not dependent on its output not being modified (eg have a flag for machine-readable output, and use that with runpytest under the hood)
pytest version: 8.3.5
The text was updated successfully, but these errors were encountered:
Uh oh!
There was an error while loading. Please reload this page.
When executing
pytester.runpytest
in an environment containing apytest
plugin that modifies the output, the result is that vanillapytester
tries and fails to parse the modified output, yielding failedassert_outcomes
.For example, the following test suite, in an environment with
pytest-pretty
installed:succeeds only when the internal testsuite is passed
-p no:pretty
, regardless of the flags with whichpytest.main
is invokedThis is an issue in certain contexts, eg kiwicom/pytest-recording#169 In that case, packaging guidelines for Arch Linux mandate running the builders without venvs. And while guidelines there mandate building packages in a chroot with only the dependencies the package needs, it is common for users to build packages outside such a chroot, and so they pick up such plugins.
One additional factor here is that diagnosing this incompatibility is difficult -- none of the plugins involved advertise this incompatibility, and the code itself doesn't suggest anything might be wrong.
Several mitigations suggest themselves, in increasing order of complexity and safety:
I'm currently writing up a proposalhave proposed that Arch should do the same. This was enabled by Option to disable plugin autoload entirely #3784pytester
documentation that it is incompatible with any plugin that modifiespytest
's outputrunpytest
will have a coherent set of bindings. eg enable explicitly setting which reporterpytest
uses for its reporting, and then haverunpytest
explicitly but overridably set the reporter (so it's always parsing the report with the reporter it was expecting to be using)pytest
a way to emit a machine-readable version of the log, so it's not dependent on its output not being modified (eg have a flag for machine-readable output, and use that withrunpytest
under the hood)pytest
version: 8.3.5The text was updated successfully, but these errors were encountered: