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

Michael Hudson mwh at python.net
Sun Jun 4 11:41:50 CEST 2006

"Thomas Wouters" <thomas at python.org> writes:

On 6/4/06, Michael Hudson <mwh at python.net> wrote: [ For non-checkins readers: Martin Blais checked in un-unittestification of teststruct, 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 testsupport for. My own project testing has gotten much more exhaustive since I started using py.test, it's just much, much more convenient.

I don't want to pull the 'do you know who I am?' routine, and I know you're addressing python-dev rather than just me, but I'm currently sitting in the same room as the guy who wrote py.test :-)

I'm also not sure what point you're trying to make: I know py.test is better than unittest, that's not what I was saying. But unittest is better than old-skool output comparison tests.

I guess you're not really replying to my mail, in fact... :)

Cheers, mwh

-- we need PB for C#

More information about the Python-Dev mailing list