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

[glyph at divmod.com]

On 02:21 pm, murman at gmail.com wrote:
>>OTOH, I'd rather there be OOWTDI so whatever the consensus is is fine
>>with me.
>
>This strikes me as a gratuitous API change of the kind Guido was
>warning about in his recent post: "Don't change your APIs incompatibly
>when porting to Py3k"

I agree emphatically.  Actually I think this is the most extreme case. 
The unit test stuff should be as stable as humanly possible between 2 
and 3, moreso than any other library.  It's one thing to have a test 
that fails because the functionality is broken.  It's much worse to have 
a test that fails because the meaning of the test has changed - and this 
is going to happen anyway with e.g. assertEquals(foo.keys(), ['some', 
'list']) which is a common enough assertion.  Mixin in changes to the 
test framework creates even more confusion and pain.  Granted, this 
change is apparently trivial and easy to understand, but each new 
traceback requires more thinking and there is going to be quite enough 
thinking going on in 2->3.

I say this from experience.  Twisted's "trial" has been burned 
repeatedly both by introducing apparently trivial changes of our own to 
our testing tool and by apparently trivial changes to the Python stdlib 
unittest module, upon which we depend.  Nothing we haven't been able to 
handle, but the 2->3 transition exacerbates this as it does all 
potential compatibility problems.

Whatever the stdlib does in this regard we'll definitely continue to 
provide an insulating layer in trial and keep both types of assertions 
for compatibility.  So maybe the answer is to use Twisted for your unit 
tests rather than worry about your own compatibility lib ;-).