[TIP] Unittest Changes

[Pekka Laukkanen]

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'.

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

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.

This wouldn't change the existing 'unittest.TestCase' API, would allow
new code to use PEP-8 style asserts, and would make it easy to use
asserts with other tools than 'unittest'. Implementation would also be
more or less trivial. How does it sound?

Cheers,
    .peke