[TIP] plguins for unittest2?

Alfredo Deza alfredodeza at gmail.com
Sun Oct 16 06:13:17 PDT 2011

On Sun, Oct 16, 2011 at 4:55 AM, Robert Collins
<robertc at robertcollins.net> wrote:
> On Sun, Oct 16, 2011 at 1:08 AM, meme dough <memedough at gmail.com> wrote:
>> Both py.test and nose (and presumably unit2) collect stdout / stderr
>> and so hide it by default.  Why is this annoying?  You see the output
>> if a test fails.
> It interferes with debugging, both adhoc and pdb. Its unnecessary
> complexity, and it -totally- fails in parallel test (via threads)
> environments.

That statement is confusing to me. How is it that capturing stdout and
stderr an interference
with debugging? If there is no failure why do you need to see
stderr/stdout from a test run?

If there is a failure both nose and py.test (not sure about unit2)
will output full captured stderr/stdout so
you can look at all that was spitted during the test run.

How is this unnecessary complexity?

And you are having issues with pdb? How so? all of the mentioned test
runners have the ability to start a
pdb on failure or stop at a given break point with the well known

You also mention parallel testing via threads - is that not
unnecessary complexity? Obviously, if you fire a thread
and you put a set_trace() it is completely understandable that you
will not be able to stop on failure.
> All in all its a terrible idea. Tests that need to capture
> stdout/stderr can easily do so.

I still don't see where you are going with this here. You *still* can
capture stdout and stderr in tests if you want
to even though the runner is muting output.

Have you even tried these tools?
> -Rob
> _______________________________________________
> testing-in-python mailing list
> testing-in-python at lists.idyll.org
> http://lists.idyll.org/listinfo/testing-in-python

More information about the testing-in-python mailing list