[TIP] Unittest Changes

[Michael Foord]

Pekka Laukkanen wrote:
> 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.
>
>   
Wow.

When I look at unittest I'll investigate this.

Thanks

Michael Foord

> Cheers,
>     .peke
>   


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/
http://www.trypython.org/
http://www.ironpython.info/
http://www.theotherdelia.co.uk/
http://www.resolverhacks.net/