[Python-ideas] hookable assertions - to support testing utilities and debugging

[Georg Brandl]

On 02/19/2015 01:55 PM, Donald Stufft wrote:

>> So from my perspective (being one of the aforementioned C
>> programmers), I see this question as not so much about the assert
>> statement per se, but rather a more philosophical question:
>> 
>> * is testing code categorically different from production code?
>> * if yes, should assert statements be handled differently in testing code?
>> * if yes, how should that difference be communicated to readers and to
>> the interpreter?
>> 
>> (FWIW, I'm personally inclined to answer the first two questions with
>> "yes", but haven't got any ideas as far as the third one goes)
>> 
>> Making the behaviour of assert statements configurable attempts to
>> duck those questions instead of answering them, so I don't see at as a
>> particularly useful approach - it makes the language more complex
>> without providing additional clarity, rather than figuring out how to
>> encode a genuinely important categorical distinction between test code
>> and production code into the design of the language.
> 
> Speaking as a not C programmer, I think the answers to the first two are
> absolutely yes, and the third one I dunno, maybe some sort of top level
> import like from __testing__ import real_assert or something.
> 
> I absolutely hate the unittest style of assertFoo, it’s a whole bunch of
> methods that I can never remember the names of and I have to go look them
> up. I think using the assert statement is completely logical for test code
> and I believe you can see this by the fact all of the methods to do checks
> in unittest are named “assert something”. I think it introduces extra cognitive
> burden for new users to have to use a whole bunch of additional methods to
> do assertions in tests TBH. The way py.test works composes nicely with the
> same kinds of expressions that you’re going to need to learn to write any
> meaningful Python, but the assertFoo methods are special cases that don’t.

+1

Georg