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

Steven D'Aprano steve at pearwood.info
Tue Jul 15 01:40:43 CEST 2008

On Mon, 14 Jul 2008 04:27:40 pm Stephen J. Turnbull wrote:

FWIW, I meant 10 != not not 10.

10 != not not 10 File "", line 1 10 != not not 10 ^ SyntaxError: invalid syntax

With respect, I think that the fact that you made an analogy with Python code that you hadn't tested, got it wrong, then corrected it, and still got it wrong, is telling. Its part of the pattern of this thread. People have repeatedly and consistently asserted that their particular favourite bike-shed colour is not just more attractive than any other colour, but supposedly objectively and logically better than any other colours. It's that second part that I object to.

When it comes to assert* versus fail* tests, this is one case where I don't believe "one obvious way to do it" should apply. A similar, and I hope uncontroversial, case is the greater-than and less-than operators. It would be frankly silly to declare that Python code should always use x < y and never y > x on the basis that there should be "one obvious way". Sometimes a particular test is most naturally written as g-t, and sometimes as l-t, and sometimes the choice between them is just arbitrary.

I believe that assert* and fail* tests are the same: while the choice is often arbitrary, sometimes a test is naturally written as an assert and sometimes as a fail. My own tests often look like this:

fail_if_spam() fail_unless_ham() assert_parrot() fail_if_spanish_inquisition()

because the specific parrot test is best written as an assertion rather than a fail. And frankly, I simply don't believe that this imposes an undue mental cost on people who might read my code.

It's certainly true that I could invert the nature of the tests:

assert_not_spam() assert_ham() assert_parrot() assert_not_spanish_inquisition()

just for the sake of consistency (and that would be a good thing why?), but only at the cost of inverting the code inside the test, which may or may not be a simple thing to do.

-- Steven

More information about the Python-Dev mailing list