[Python-Dev] unittest's redundant assertions: asserts vs. failIf/Unlesses
Michael Foord
fuzzyman at voidspace.org.uk
Tue Apr 8 10:58:46 CEST 2008
Guido van Rossum wrote:
> On Wed, Mar 19, 2008 at 5:16 PM, Jeffrey Yasskin <jyasskin at gmail.com> wrote:
>
>> On Wed, Mar 19, 2008 at 2:15 PM, <glyph at divmod.com> wrote:
>> >
>> > 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.
>>
>> This is convincing for me. Move my +1 back to 3.1.
>>
>
> Same here; let's tread carefully here and not change this with 3.0.
> Starting to deprecate in 3.1 and killing in 3.3 would be soon enough.
> I like using only the assertKeyword variants, removing assert_, fail*,
> and assertEquals. However I don't like changing assertTrue and
> assertFalse to insist that the value is exactly True or False -- if
> you really care that much, let's add assertIs(x, y) which asserts that
> x and y are the same object. I also think that all tests should use
> the operator their name implies, e.g. assertEqual(x, y) should do
> something like
>
> if x == y:
> pass
> else:
> raise AssertionError(...)
>
> rather than
>
> if x != y:
> raise AssertionError(...)
>
> Someone please open a bug for this task.
>
>
This sounds like a good compromise and I'm happy to take on the cleanup
- unless someone else beats me to it. I guess it should wait until 3.0
final is out of the door before adding the DeprecationWarnings.
Michael Foord
More information about the Python-Dev
mailing list