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

[Steven D'Aprano]

On Tue, 15 Jul 2008 06:32:53 pm Stephen J. Turnbull wrote:
> 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.

The ad hominem fallacy does not mean "somebody pointed out I made a 
silly mistake". It is not a fallacy to reject a person's argument 
because it is hastily or carelessly made.

However, fair is fair -- I too have to accept a slice of humble pie. In 
*my* haste to make my point, I neglected to actually make the point I 
intended to. I went on to write "It's part of the pattern of this 
thread" but didn't explain why. Namely that with so many people trying 
to push their personal preference, and signs of frustration on both 
sides, people are making unsupported statements of opinion as if they 
were facts, and generally getting sloppy. Ironic, yes?

Having communicated poorly, and by doing so giving you offence, I will 
accept an appropriate fish-slapping.


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

But I'm using that same framework, so decisions made regarding that 
framework are going to impact me. Terry Reedy says that "stdlib modules 
are suggestions and examples, not commands", which is strictly true but 
I think he discounts just how strong the stdlib's influence is. Perhaps 
large projects, and tiny ones, are free to go their own way, but in my 
experience (such that it is), small projects tend to follow the stdlib.


> So it *is* about communication with 
> other developers, and it *does* make sense to avoid proliferation of
> redundant vocabulary.

Certainly redundant vocabulary has a cost, but it also has a benefit. At 
least for those people (including myself) who frequently think of a 
unit test as a sequence of potential failures rather than expected 
successes. Only if the code "fails to fail" does it pass the test, and 
so I often find fail* tests more suitable. YMMV.



-- 
Steven