classification
Title: there is no easy way to force unittest.main to use stdout rather than stderr
Type: behavior Stage: resolved
Components: Library (Lib) Versions: Python 3.4
process
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: michael.foord Nosy List: bialix, michael.foord, r.david.murray
Priority: normal Keywords:

Created on 2012-10-08 11:58 by bialix, last changed 2012-10-09 10:45 by michael.foord. This issue is now closed.

Messages (4)
msg172375 - (view) Author: Alexander Belchenko (bialix) Date: 2012-10-08 11:58
Why by default unittest.main (which uses unittest.TextTestRunner) prints everything to stderr. What the reason behind this behavior?
It makes very inconvenient to run big test suite with less, i.e.

python test.py | less 

or

python test.py > test.log

does not show me failed tests. They all go to stderr. Why?

Another thing: there is no easy way to override this. I have to subclass either TestProgram or TextTestRunner and force sys.stdout rather than sys.stderr. E.g.

class TestProgram(unittest.TestProgram):

    def runTests(self):
        if self.testRunner is None:
            self.testRunner = unittest.TextTestRunner(stream=sys.stdout, verbosity=self.verbosity)
        result = self.testRunner.run(self.test)
        sys.exit(not result.wasSuccessful())

if __name__ == '__main__':
    TestProgram()

Although it works for me I feel there is something wrong. Am I the only person who needs test output on stdout?
msg172384 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2012-10-08 15:20
I think the reason is that this enables you to easily see if the tests generate any output to stdout.  This was important when unittest was introduced into python, because some of our tests at that time were still written to check the stdout output against "known good" output, and in the process of converting them we would make sure that stdout was empty after the unittest run.  Those tests have all been converted a fairly long time ago now.

It is an interesting question whether this decision could be revisited.  The problem is that there may well be other people depending on the current behavior, which many people may view as the correct behavior.  I myself am neutral on the question, though I have experienced the annoyance of having to run unittest twice when I forget that the output goes to stderr...the second time to do the equivalent of 'python test.py 2>&1 | less'.
msg172386 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2012-10-08 15:20
I'm pretty sure this should be closed as "won't fix" or "invalid", but I'll leave that to Michael, who is the current maintainer of unittest.
msg172473 - (view) Author: Michael Foord (michael.foord) * (Python committer) Date: 2012-10-09 10:45
Unfortunately subclassing core components is the *intended* mechanism for customising unittest behaviour. Changing this is possible, but is a big job with very extensive changes.

I don't think this request is *invalid* per-se, but it isn't something that we're about to change and there are much higher priorities for providing customization points for unittest. Closing as wont fix, but eventually hopefully it will be possible to do without requiring changes in unittest.

(And it *can't* be fixed in Python 2.6 or 2.7 as it isn't a bug and no new features are being added to these versions - so I've changed the tags even though I'm closing it.)
History
Date User Action Args
2012-10-09 10:45:20michael.foordsetstatus: open -> closed
versions: + Python 3.4, - Python 2.6
messages: + msg172473

assignee: michael.foord
resolution: wont fix
stage: resolved
2012-10-08 15:20:46r.david.murraysetnosy: + michael.foord
messages: + msg172386
2012-10-08 15:20:02r.david.murraysetnosy: + r.david.murray
messages: + msg172384
2012-10-08 11:58:20bialixcreate