[Python-Dev] unittest's redundant assertions: asserts vs. failIf/Unlesses

Ron Adam 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)
>> "fail_unless_equal".
> 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 mailing list