[Python-Dev] [Python-checkins] r46603 - python/trunk/Lib/test/test_struct.py

[Thomas Wouters]

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