A better unittest

[John Roth]

"Thomas Heller" <theller at python.net> wrote in message
news:3ckier9a.fsf at python.net...
> I'm moving more and more to TDD (test driven development [1]), which
> makes tests an integral part of the development process.  Failing
tests
> are ocurring very often with this development style, because you write
> the tests first and then implement the functionality.
>
> Having said this, I'm not really happy with the output of
> unittest. Consider the following testcase:

[snip]

> What do people think? Is this a useful change, and should I submit a
> patch?

I don't think I'd find it useful for two reasons. One is that it doesn't
get rid of enough clutter; removing the stack trace cuts the output
down by maybe 50%, and leaves in a good deal of poorly formatted
visual clutter.

The other reason is that it's really hard to figure out when the error
is expected so the stack trace is redundant, and when it's not expected
so that the stack trace includes useful information.

In any case, I really only expect *one* test to fail at any point
in time, and I suppose that I'm of the "more information is better"
school of thought. If more than one test fails, I suspect that I've
done something really stupid on the last change.

-1

John Roth

>
> Thomas
>
> [1] Kent Beck: Test Driven Development: by example. Addison Wesley,
2002.
>     ISBN 0-321-14652-0