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

Ron Adam rrr at ronadam.com
Sun Jul 13 20:55:24 CEST 2008

Antoine Pitrou wrote:

Ben Finney <bignose+hates-spam benfinney.id.au> writes:

That would better be written (preferring PEP 8 names) "failunlessequal". 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 AssertionError.."

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:

          Wrong_Result_Returned
          Unexpected_Exception_Raised


   assertTestRaises(test, expect, ref="")

       raises on failure:

          No_Exception_Raised
          Wrong_Exception_Raised

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?

Ron

More information about the Python-Dev mailing list