On Jun 01 2016, holger krekel <hol...@merlinux.eu> wrote: > On Tue, May 31, 2016 at 10:17 -0700, Nikolaus Rath wrote: >> On May 28 2016, holger krekel >> <holger-to2cgvpyn1lsq35pwsn...@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.« _______________________________________________ pytest-dev mailing list pytest-dev@python.org https://mail.python.org/mailman/listinfo/pytest-dev
