[TIP] Unittest Changes

Pekka Laukkanen peke at iki.fi
Mon Jul 28 15:30:14 PDT 2008


2008/7/22 Michael Foord <fuzzyman at voidspace.org.uk>:
> Pekka Laukkanen wrote:
>> 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.
>
> If you do try it - post the results back to the list.

An example implementation of asserts module is attached. It's code is
copied from Python 2.5.2 source code with following changes:

- Asserts are functions instead of methods.
- Asserts have PEP8-style names.
- Assert names use 'assert_' variants preferred by Guido.
- self.failureException -> FAILURE_EXCEPTION (as easy to override if needed)

A trivial example using this module is also attached. This example has
same tests using both 'assert_xxx' and traditional 'self.assertXxx'
variants, and at least for me the former versions are easier to read.
Test results are otherwise identical, but the failing test using
'asserts.fail' has a bit longer traceback than the one using
'self.fail'. Changing 'unittest.TestResult._exc_info_to_string' method
so that also traceback levels from 'asserts' module are ignored
shouldn't be too hard, though. Additionally it would make sense to
change old assert methods so that they directly use functions from
'asserts' so that there's no code duplication.

Main benefits from this approach would be:

- Stand-alone asserts are available for unittest but also for other
tools (no need to re-implement the wheel every time).
- Asserts have PEP8-style names (and naming convention suggested by BDFL).
- 100% backwards compatibility.

Cheers,
    .peke
-------------- next part --------------
A non-text attachment was scrubbed...
Name: asserts.py
Type: application/octet-stream
Size: 2622 bytes
Desc: not available
Url : http://lists.idyll.org/pipermail/testing-in-python/attachments/20080729/ab7f37f8/attachment.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_fib.py
Type: application/octet-stream
Size: 1564 bytes
Desc: not available
Url : http://lists.idyll.org/pipermail/testing-in-python/attachments/20080729/ab7f37f8/attachment-0001.obj 


More information about the testing-in-python mailing list