[TIP] Unittest Changes

[Pekka Laukkanen]

2008/7/22 Michael Foord <fuzzyman at voidspace.org.uk>:
> Pekka Laukkanen wrote:
>>
>> 2008/7/21 Michael Foord <fuzzyman at voidspace.org.uk>:
>>
>>>
>>> Pekka Laukkanen wrote:
>>>
>>>>
>>>> 1) Having assertions available as static methods in a separate module.
>>>> This would a) make using them with other code easier, and b) make
>>>> lines shorter since there would be no need for "self.". With JUnit 4
>>>> and Java 5 you can do """import static org.junit.Assert.assertNull"""
>>>> and this addition to Python would allow similar """from
>>>> unittest.asserts import assertNone""".
>>>>
>>>
>>> Interesting idea. I wonder if it could be done without altering the
>>> semantics of the existing API?
>>>
>>
>> There could either be a separate 'asserts' module or 'unittest' could
>> become a higher level module with 'asserts' as a submodule. The latter
>> change would require changing 'unittest.py' to 'unittest/__init__.py',
>> but that should not break backwards compatibility. After adding
>> 'asserts' (sub)module, assert methods in 'unittest.TestCase' could
>> just call appropriate functions in 'asserts'.
>>
>
> Would be worth an experiment to see if it works.

At least I don't see any reason why it would not. There's some extra
work in changing filtering of the traceback so that not only lines
originating inside 'unittest' but also inside 'asserts' are ignore.
That shouldn't be too hard, though.

>> Nice that you like the idea. I've always wondered why
>> 'unittest.TestCase' has those assert methods when in JUnit they are in
>> separate class. 'unittest' is a pretty direct JUnit port (even
>> according to its docs) so I wonder why the design has been changed.
>>
>>
>>>>
>>>> 2) Having PEP-8-style aliases for asserts. PEP-8 reminds that
>>>> consistency within a module is most important, but now my test modules
>>>> have inconsistent lines like
>>>> """self.assertEquals(do_something_interesting, expected_value)""".
>>>> Asserts can be also used with non-test code (and above point would
>>>> make that even easier), and then adhering PEP-8 is even more
>>>> important.
>>>>
>>>
>>> Off the table for standard library inclusion, see the BDFL pronouncement
>>> on
>>> Python-Dev.
>>>
>>
>> Do you mean "Unittest PEP do's and don'ts (BDFL pronouncement)" [1]?
>> It only mentions that old camelCase methods can't be removed and API
>> can't change in backwards incompatible manner, but there's nothing
>> about new PEP-8-style aliases. The Python-Dev discussion was too long
>> for me to read fully, so I might have missed another pronouncement,
>> though.
>>
>> [1] http://mail.python.org/pipermail/python-dev/2008-July/081263.html
>>
>
> And this follow up:
>
> http://mail.python.org/pipermail/python-dev/2008-July/081269.html
>
> Specifically:
>
>> Presumably new methods should *not* follow PEP8 but be internally
>> consistent
>> with the existing API?
>
> Right again.
>
> PEP8'ification of unittest methods - old and new - really is off the table
> for standard library inclusion (honestly).

There's still nothing about adding PEP8-style aliases. I totally agree
that in one module you should not have both methods having both
under_score and camelCase names. Anyway, if the first idea about
having a separate 'asserts' module is implemented, then new functions
there should have PEP8 style names since its totally new code. The
suggestion below takes this into account while keeping the old
'unittest' API.

>> My suggestion to implement above ideas is this:
>>
>> 1) Create new 'asserts' module (either as top-level module or
>> submodule of 'unittest')
>> 2) Add only PEP-8 style static functions to 'asserts'.
>> 3) Add only one version of each assert function (i.e. only
>> 'assert_equal' favored by BDFL and not 'fail_unless_equal' or
>> 'assert_equals').
>> 4) Change 'unittest.TestCase' so that its assert methods use functions
>> from 'asserts'.
>> 5) Add new assert functions to 'asserts' in PEP-8 format and have
>> matching assert method in 'unittest.TestCase' in camelCase format.


Cheers,
    .peke