A better unittest

[Thomas Heller]

"John Roth" <johnroth at ameritech.net> writes:

> "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.
> [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.
> 
Hm, the latest version of the patch which I posted typically prints this:

======================================================================
FAIL: test_failUnlessEqual (__main__.FailingTests)
----------------------------------------------------------------------
TestFailed: 0 != 1
  File "xunit.py", line 12, in test_failUnlessEqual
    self.failUnlessEqual(self.a, self.b)

Is this poorly formatted? I won't argue about this.
Anyway, this is IMO the information I want to have:
filename, line number, source code line, and the actual#
values which made the test fail.

> 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.

It doesn't look too much to a traceback anymore.

> 
> 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.

This is irrelevant. I did post an example with multiple failures/errors
to show the output for different cases.

Concerning the 'more is better': If the test crashes (raises an
unexpected exception), the full traceback is printed.
If the test fails because a condition is not fulfilled, I'm *not*
interested to see how unittest raises this error.

Thomas