[issue16164] there is no easy way to force unittest.main to use stdout rather than stderr
Michael Foord added the comment: 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.) -- assignee: - michael.foord resolution: - wont fix stage: - committed/rejected status: open - closed versions: +Python 3.4 -Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16164 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16164] there is no easy way to force unittest.main to use stdout rather than stderr
New submission from Alexander Belchenko: 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? -- components: Library (Lib) messages: 172375 nosy: bialix priority: normal severity: normal status: open title: there is no easy way to force unittest.main to use stdout rather than stderr type: behavior versions: Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16164 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16164] there is no easy way to force unittest.main to use stdout rather than stderr
R. David Murray added the comment: 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 21 | less'. -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16164 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16164] there is no easy way to force unittest.main to use stdout rather than stderr
R. David Murray added the comment: 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. -- nosy: +michael.foord ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16164 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
