[pytest-dev] Preserving capture fd from fixture setup?

[Nikolaus Rath]

On Jun 01 2016, holger krekel <holger at merlinux.eu> wrote:
> On Tue, May 31, 2016 at 10:17 -0700, Nikolaus Rath wrote:
>> On May 28 2016, holger krekel <holger-TO2CgvPYN1Lsq35pWSNszA at public.gmane.org> wrote:
>> > Hi Nikolaus,
>> >
>> > On Thu, May 19, 2016 at 12:34 -0700, Nikolaus Rath wrote:
>> >> Hello,
>> >> 
>> >> I am testing a server. I am starting the server in a subprocess from a
>> >> fixture, and then issue requests to it from various tests. Unfortunately
>> >> this seems to have one big drawback: when a test fails, the capture
>> >> plugin does not display any output from the server process.
>> >>
>> >> After looking at the code, I think this is because the capture plugin
>> >> creates a new file descriptor for each test phase (setup, call,
>> >> teardown).
>> >
>> > it reuses the same file descriptor for capturing IIRC.  After each
>> > phase (setup, call, teardown) the FD is reset to position 0.
>> 
>> Hmm. Yeah, on closer inspection my test case was flawed - adding a
>> .flush() at the end of the setup code made the output appear in the
>> right spot. But my original problem remains.
>> 
>> 
>> > Is your problem that the server is started during fixture setup
>> > and you'd like to see its standard out/err during the test call phase?
>> 
>> Exactly.
>
> I guess you could write some conftest.py hook which transfers the output
> from the setup phase to the call phase so you can see it when a test call
> phase fails.  Something like:
>
> https://pytest.org/latest/example/simple.html#making-test-result-information-available-in-fixtures
>
> shows a bit of the mechanics for that although it is not
> precisely yet what you are asking for.

FWIW, this is what I'm now using (and it seems to work reasonably well):

https://bitbucket.org/nikratio/python-llfuse/src/552c0ccdaa5fbeeb6d5e1907554ba8b0a2ba6972/test/pytest_checklogs.py?at=default&fileviewer=file-view-default#pytest_checklogs.py-122

It was a little surprising that I had to get the reference to the
capture object via the plugin-manager. The fixture was unusable at this
point because it seems to be initialized later.

Best,
Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«