-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
Capturing, with and without stdlib logging #2079
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
I will try to explain what's happening. First, let's remember that The problem is that your example is configuring logging at the module level. What's happening is this:
That's why you don't see Your All boils down to the fact that you are configuring the module at the module level, which I know is standard practice. Unfortunately I'm not sure how you can use I suggest that you use the pytest-catchlog instead, which provides a |
Thank you first and foremost for pointing me to pytest-catchlog, I will see if that can solve my issue. As for the confusion about capturing... Thank you for explaining that 'capturing' in the context of the command-line flags, and 'capturing' in the context of capsys/capfd, are two wholly distinct and separate things. Perhaps some terminology changes could be made to prevent such confusion for other users? In the context of the command-line flags, I feel the term 'echoing' could be used: the user chooses whether he wants to have the actual stderr/stdout output of his command echoed in pytest's output or not, and if yes through what mechanism. |
How about adding a note about it in the capture page explaining the distinction? A PR would be most welcome. 😁 Closing this for now then, feel free to reopen if you feel otherwise. |
Pytest 3.1.0 broke our current use of capfd, but that doesn't seem to be a good way to handle capturing of log messages. (pytest-dev/pytest#2079) So instead use pytest-catchlog, which was recommended in that issue and seems to be maintained.
Pytest 3.1.0 broke our current use of capfd, but that doesn't seem to be a good way to handle capturing of log messages. (pytest-dev/pytest#2079) So instead use pytest-catchlog, which was recommended in that issue and seems to be maintained.
Pytest 3.1.0 broke our current use of capfd, but that doesn't seem to be a good way to handle capturing of log messages. (pytest-dev/pytest#2079) So instead use pytest-catchlog, which was recommended in that issue and seems to be maintained.
capfd.readouterr().err is hit and miss for the logged messages, for whatever reason. Maybe [1] explains it, but I didn't bother to read. [1] pytest-dev/pytest#2079
So I find myself rather confused by output capturing.
Let's start by quoting the manual:
I run this with
pytest test_me.py
and I get a pass.Then I run this with
pytest -s test_me.py
, and I still get a pass. Which according to the manual doesn't make sense.-s
is described as disabling capturing. So either I'm not grasping something crucial, or the manual is wrong, or there's a bug in the implementation of-s
.I then become even more confused when I try to test the behaviour of the stdlib logging module. I don't mean testing the module, but testing that my app emits the right log entries in the right circumstances.
So I make this example code:
I run this without
-s
:Then I run it with
-s
:So at first sight this makes some sense. The logging output happens, it just gets captured somewhere, unless I specify
-s
. So in this case-s
does seem to work exactly as described, the only remaining issue is that capsys for some reason doesn't capture what logging emits on sys.stdout...So we do the obvious next step and replace all occurrences of capsys with capfd!
Run without
-s
:Run with
-s
:... What? Without
-s
the logging output still vanishes into thin air, but now it has actually been captured with-s
? So in this case the flag actually turns capturing on, when the description is that it turns capturing off?Could someone explain what I'm missing here, or what I'm doing wroing?
(I'm aware I could reconfigure my logger so that it goes to a file or something and avoid this, but I'd prefer to stick as closely as possible to my production code)
The text was updated successfully, but these errors were encountered: