-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
Using capfd
in fixture breaks output capturing
#4428
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
using the capfd fixture i not a noop, i beleive a integration point with it is problematic, but currently i dont recall the details |
capfd
in fixture breaks output capturing
You are right! Adjusted the bug title. |
based on https://docs.pytest.org/en/latest/capture.html#accessing-captured-output-from-a-test-function this is expected behaviour |
@nicoddemus i believe this is yet another indication that a completely different structure for capture is needed |
@RonnyPfannschmidt Could you elaborate on how this is expected behavior? I read the link several times now, but I don't understand how it explains what I am seeing. |
@Nikratio the fixture captures the actual output, so it can be used in the test, its not passed trough to the outer pytest |
Is there any workaround? |
for example the capture fixtures have a method contextmanager to disable them for a portion of code |
Hmm. Not sure I follow. I do not want to disable them, I want them to work.. |
So capsys / capfd doesn't rely on (and is not compatible with) the "builtin" capturing of stdout/stderr? That would explain my problem, I wasn't sure whether it was worth opening a separate issue so maybe it's not if this is a known issue: my tests are interacting with a subprocess which is created in a fixture and inherits the test runner's stdout/stderr (just a The output of that subprocess is correctly captured by pytest itself (as part of capturing the overall stdout/stderr), however neither capsys nor capfd can see it. Which makes sense if they just swap out the fds/streams locally during the test, they're too late for the subprocess to be impacted. Am I correct that capfd-ing the subprocess's fixture would work, but then the subprocess's output wouldn't be displayed by pypy anymore (on test failure)? And even if I tried to manually inject it e.g. out, err = capfd.readouterr()
with capfd.disable():
print(out)
print(err, file=sys.stderr) I would still be missing bits if the test used readouterr internally? |
Also somewhat of a duplicate of #3448 ? |
… valid Seems like a good idea to better keep track of the log of an Odoo used to testing, and avoid silently ignoring logged errors. - intercept odoo's stderr via a pipe, that way we can still write it back out and pytest is able to read & buffer it, pytest's capfd would not work correctly: it breaks output capturing (and printing on failure); and because of the way it hooks in it's unable to capture from subprocesses inheriting the standard stream, cf pytest-dev/pytest#4428 - update the env fixture to check that the odoo log doesn't have any exception on failure - make that check conditional on the `expect_log_errors` marker, this way we can mark tests for which we expect errors to be logged, and assert that that does happen
Consider the following code:
The output is as expected:
However, if I uncomment the "noop" fixture, no output is captured anymore:
The text was updated successfully, but these errors were encountered: