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

Thomas Wouters thomas at python.org
Sun Jun 4 11:55:36 CEST 2006

On 6/4/06, Michael Hudson <mwh at python.net> wrote:

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

I'm sorry, I guess I was misunderstanding your mail. I thought Tim's reaction was "we want unittest because we want structure", and your reaction was "yes, we need more structure", both of which I took as "I don't really know anything about py.test" :) Since no one argued against structure, I'm not sure where the structure argument comes from. As for not knowing about your "involvement" with py.test, well, how could I? py.test doesn't list an 'author' anywhere I could find, the webpage just says "last edited by Holger", and the debian package came with no CREDITS file other than the 'copyright' file, which doesn't list you ;-P

Credit-+=-mwh-where-credit-is-due--now-please-merge-with-unittest-already'ly y'rs,

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/f65fe514/attachment.htm

More information about the Python-Dev mailing list