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

Stephen J. Turnbull stephen at xemacs.org
Tue Jul 15 10:32:53 CEST 2008

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 "", 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*.

More information about the Python-Dev mailing list