[Python-Dev] Proposed unittest changes

[Nick Coghlan]

Steve Holden wrote:
> Ben Finney wrote:
>> To be clear, I take it you're in favour of the following names (with
>> no aliases):
>>
>>     assert_equal                assert_not_equal
>>     assert_is                   assert_is_not
>>     assert_in                   assert_not_in
>>     assert_almost_equal         assert_not_almost_equal
>>
>> and so on; i.e. that 'assert_is_not' breaks the obvious pattern set by
>> the others, in the interest of matching Python's 'is not' grammar.
>>
> Well, I'd have said "in the interest of reading correctly in English", 
> though I have to acknowledge this may not be an issue for many Python 
> users whose first language not is English. "assert_not_is" is just 
> dissonant to my ears.

The two reasons aren't that far apart, given that Python's grammar uses 
"is not" because it makes more sense in English. One thing to remember 
is that the word 'is' is actually implied in all of the contracted 
phrases above other than those already including it explicitly.

"x is equal to y"
"x is not equal to y"
"x is y"
"x is not y"
"x is in y"
"x is not in y"
"x is almost equal to y"
"x is not almost equal to y"

As for which phrasing I personally prefer, unit tests and method names 
are areas where I'm quite happy to paint the bike shed the same colour 
as the house :)

Cheers,
Nick.

P.S. Deciphering that somewhat strained metaphor: I don't have a strong 
preference with regards to the unit test method names. While I tend to 
go with the assert* variants when left to my own devices, I have no 
problem sticking to the fail* variants when updating a test that uses 
them. Camel-case vs underscores in method names isn't something that 
particularly worries me either.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org