[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:
>
> "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 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 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<wink>'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