[Python-Dev] unittest's redundant assertions: asserts vs. failIf/Unlesses
steve at pearwood.info
Wed Jul 16 01:54:56 CEST 2008
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
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.
More information about the Python-Dev