[Python-Dev] unittest's redundant assertions: asserts vs. failIf/Unlesses
rrr at ronadam.com
Sun Jul 13 20:55:24 CEST 2008
Antoine Pitrou wrote:
> Ben Finney <bignose+hates-spam <at> benfinney.id.au> writes:
>> That would better be written (preferring PEP 8 names)
> Which is still a double negative ("fail" and "unless" are both negative words).
>> That's another reason to avoid "assert" in the name: these methods
>> *don't* necessarily use the 'assert' statement.
> But all those constructs (assert, assertEqual, etc.) raise the same exception
> type named AssertionError which, if you care for naming consistency, is more
> important than whether or not they are implemented in terms of each other. :-)
Regarding: "all those constructs ... raise the same exception type named
As an experiment a while back (out of frustration), I created some tests
that used more specific (local unittest module only) exceptions. The
clarity of the failed errors and the mental effort to debug the problems
was much improved for me.
I sub-classed unittest.TestCase, and added two new methods and a few local
and unique test-only exceptions.
* test -> a test function to call
* ref -> addition helpful debug info
assertTestReturns(test, expect, ref="")
raises on failure:
assertTestRaises(test, expect, ref="")
raises on failure:
These more specific exceptions (over plain AssertionError), allowed for
more specific error reports.
A testcase with an error would produce a standard python exception so you
know instantly that you need to fix the test rather than the code being tested.
Also the more specific exception code can better handle some cases where a
wrong traceback would be returned. ie.. the test code traceback rather
than the code being tested traceback.
Is there any interest in going in this direction with unittests?
More information about the Python-Dev