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