From e382ed4245c30526bf107c361704760ec6e2c716 Mon Sep 17 00:00:00 2001 From: holger krekel Date: Mon, 7 Apr 2014 13:42:48 +0200 Subject: [PATCH] fix issue439: clarify that capsys/capfd capture output during test execution, not test setup. --- doc/en/capture.txt | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/doc/en/capture.txt b/doc/en/capture.txt index 19bb3ca13..b3140e23c 100644 --- a/doc/en/capture.txt +++ b/doc/en/capture.txt @@ -84,11 +84,9 @@ of the failing function and hide the other one:: Accessing captured output from a test function --------------------------------------------------- -The :ref:`funcarg mechanism` allows test function a very easy -way to access the captured output by simply using the names -``capsys`` or ``capfd`` in the test function signature. Here -is an example test function that performs some output related -checks:: +The ``capsys`` and ``capfd`` fixtures allow to access stdout/stderr +output created during test execution. Here is an example test function +that performs some output related checks:: def test_myoutput(capsys): # or use "capfd" for fd-level print ("hello") @@ -108,8 +106,10 @@ test from having to care about setting/resetting output streams and also interacts well with pytest's own per-test capturing. -If you want to capture on ``fd`` level you can use +If you want to capture on filedescriptor level you can use the ``capfd`` function argument which offers the exact -same interface. +same interface but allows to also capture output from +libraries or subprocesses that directly write to operating +system level output streams (FD1 and FD2). .. include:: links.inc