[Python-Dev] Unittest PEP do's and don'ts (BDFL pronouncement)

[Guido van Rossum]

On Wed, Jul 16, 2008 at 1:03 PM, Michael Foord
<fuzzyman at voidspace.org.uk> wrote:
> Guido van Rossum wrote:
>> 2. Radical changes to the API are off the table. If a radically
>> different API is to be accepted, the road to such acceptance is not a
>> design-by-committee PEP, but adoption of a 3rd party module with a
>> multi-year track record. If you have radically different ideas about
>> how to do unittesting, by all means implement them and try them out
>> and try to get a large audience to use them. When you are successful
>> in all that, *then* we'll talk about adoption into the standard
>> library.

> I assume this doesn't rule out the addition of [some of..] the new
> convenience test methods?

Correct.

>> 3. I like assertEqual better than failUnlessEqual (and similar for all
>> assert* versions in favor of their fail* alias), and I don't like that
>> there is both assertEqual and assertEquals. But rule #1 means we have
>> to live with the aliases. At best we can discourage the undesirables
>> by documenting them out of existence.

> Presumably new methods should *not* follow PEP8 but be internally consistent
> with the existing API?

Right again.

> Does this mean that new methods should be added with *both* assert* and
> fail* names?

No, I don't see any reason to perpetuate that particular design snafu.
I said "live with the aliases", not "add more of them".

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)