[Python-Dev] [Python-checkins] r46603 - python/trunk/Lib/test/test_struct.py (original) (raw)

Thomas Wouters thomas at python.org
Sun Jun 4 11:13:21 CEST 2006

On 6/4/06, Michael Hudson <mwh at python.net> wrote: [ For non-checkins readers: Martin Blais checked in un-unittestification of test_struct, which spawned questions form Neal and me about whether that's really the right thing to do. I also foolishly<0.5 wink> siggested that, if we switch away from unittest, we switch to py.test instead of the old unstructured tests ]

"Tim Peters" <tim.peters at gmail.com> writes:

> unittest, and especially doctest, encourage breaking tests into small > units. An example of neither is testdescr.py, which can be a real > bitch to untangle when it fails.

Also, there is an advantage to have more structure to the tests; if all of python's tests used unittest, my regrtest -R gimmickery would be able to identify tests, rather than test files, that leaked and I'm pretty sure that this would have saved me a few hours in the last couple of years. Also, you can more easily identify particular tests that fail intermittently. Etc.

I'm not arguing against structure, just against all the unittest cumber. For example, py.test doesn't do the output-comparing, and it does require you to put tests in separate functions. However, it doesn't require (but does allow) test classes. Test-generators are generators that return tests, which are then run, so that you can have separate tests for runtime-calculated tasks, and yet still have them be separate tests for error reporting and such. py.test also allows tests to print during execution, and that output is kept around as debug output: it's only shown when the test fails. It also comes with a convenient command-line tool that can run directories, modules, individual tests, etc -- which, for unittest, I always have to copy-paste select bits out of regrtest and test_support for. My own project testing has gotten much more exhaustive since I started using py.test, it's just much, much more convenient.

I'm not arguing for inclusing of py.test so much as unittest taking over most of its features (obviously not for 2.5, though.) I really don't see the point of test-classes the way we currently have them. When I look at the stdlib tests, most of the TestCases have methods that don't really need to be in a single TestCase (and I believe the 'normal' JUnit style has them as separate classes in those cases. yikes.) I don't really see the point in using all the variations of 'assert' as methods, except for 'assertRaises'. Et cetera. py.test's approach is simpler, more direct, easier to read and write, and just as powerful (and in the case of test-generators, more so.) And you can very easily emulate the unittest API with py.test ;-)

Since there's time for 2.6, I'd encourage everyone to look at py.test, maybe we can just merge it with unittest ;P

-- Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/python-dev/attachments/20060604/54a653ea/attachment.html

More information about the Python-Dev mailing list