RetroSearch Browse

Tue Jul 15 12:58:57 CEST 2008 · https://mail.python.org/pipermail/python-dev/2008-July/081134.html

Ben Finney wrote:
>>        self.fail_if_almost_equal('were already on the 34th column before'
>>                                  'writing anything substantive',
>>                                  self.testedobject.tested_method(arg1, arg2 +
>>                                                                  arg3, arg4)
>>        # Imagine typing and line wrapping dozens more tests like this
> 
> Yikes. Why are you using such huge indents? Break the line where
> indents won't be so enormous.

While true, that doesn't change the fact that fail_if_almost_equal is an 
undesirably long method name.

> I'm very much in favour of having the namessay exactly what they're
> testing. They need to be long because there are many of them doing
> slightly-different things, so need careful disambiguation.

The "almost_equal" methods for floating point comparison are the main 
culprits for excessive method length, closely followed by the 
"fail_unless" variants.

(21, 'failUnlessAlmostEqual') -> 24 with underscores
(21, 'assertNotAlmostEquals') -> 25 with underscores
(20, 'assertNotAlmostEqual')  -> 24 with underscores
(18, 'assertAlmostEquals')    -> 20 with underscores
(17, 'failIfAlmostEqual')     -> 20 with underscores
(17, 'assertAlmostEqual')     -> 19 with underscores
(16, 'failUnlessRaises')      -> 18 with underscores
(15, 'failUnlessEqual')       -> 17 with underscores
(15, 'assertNotEquals')       -> 17 with underscores
(14, 'assertNotEqual')        -> 16 with underscores
(12, 'assertRaises')          -> 13 with underscores
(12, 'assertEquals')          -> 13 with underscores
(11, 'failIfEqual')           -> 13 with underscores
(11, 'assertFalse')           -> 12 with underscores
(11, 'assertEqual')           -> 12 with underscores
(10, 'failUnless')            -> 11 with underscores
(10, 'assertTrue')            -> 11 with underscores
(7, 'assert_')                ->  7 with underscores
(6, 'failIf')                 ->  7 with underscores
(4, 'fail')                   ->  4 with underscores

One option for rationalising the API would be to merely keep the 
shortest version of each phrase (i.e. use assert* instead of 
fail_unless* for the positive tests and fail_if* instead of assert_not* 
for the negative tests, and always drop the trailing 's' from 'equals'). 
This simple rule would eliminate 12 of the 20 methods (including the 
four longest method names and 7 of the longest 9), leaving the following 
minimal set of methods:

fail_if_almost_equal (20)
assert_almost_equal  (19)
assert_raises        (13)
fail_if_equal        (13)
assert_equal         (12)
assert_              (7)
fail_if              (7)
fail                 (4)

Adding in possible positive and negative forms of the proposed new 
methods (using words more appropriate for a method rather than copying 
the infix operators):

fail_if_identical (17)
fail_if_contains  (16)
assert_identical (16)
assert_contains  (15)

Cheers,
Nick.

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

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2008-July/081134.html below:

Consolidating names and classes in the `unittest`module (updated 2008-07-15)