[TIP] Unittest Changes

[Michael Foord]

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.

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


Michael

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


-- 
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/