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

[Stephen J. Turnbull]

Steven D'Aprano writes:
 > 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.

It's telling only if you ignore the fact that it's the ad hominem fallacy.

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

In the context you were talking about, where you don't need to show
anybody your tests, I don't see any reason why TOOWTDI should apply.
In a debugging context, I don't see any reason why it should, either.

But here we're talking about the standard unit-testing framework,
which is used by Python itself.  So it *is* about communication with
other developers, and it *does* make sense to avoid proliferation of
redundant vocabulary.  Some of us have enough trouble remembering when
parentheses are redundant, as you noticed.

Regression test suites aspire to full coverage.  If you mix assert*
and fail* clauses, you are going to need to invert one or the other to
determine whether there are cases that are missed.

IMO those are strong indications that only one of the pair should be
used in a test suite.

 > I believe that assert* and fail* tests are the same:

In logic, they are.  I just think that assert* is much more natural in
several simple cases, such as the pure regression test where you use
Python X.Y to compute foo(), and add "assertEqual(foo(), pyXYresult)"
to the test suite.  I'd be a lot more sympathetic if you'd describe
a similarly plausible and generic application for fail*.