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

[Steven D'Aprano]

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 "<stdin>", 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