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

[Neal Norwitz]

On 6/3/06, Thomas Wouters <thomas at python.org> wrote:
>
> Heh, my reaction was both "huh?" and "yay" at the same time. I thought
> unittest was still preferred for the stdlib testsuite? I don't particularly
> see the benefits of unittest myself, although I admit it's a _tad_ cleaner
> than most of the non-unittest scripts the stdlib had before. However, having
> written a few tests with py.test, in particular test-generators, well,
> unittest's just cumbersome ;-P

unittest inherited too much from JUnit IMO (does that make it
Java-ick?).  I don't love it, but it's much better than the old style
as Tim described.

> I'm not arguing for (or against) py.test, just wondering what the support
> and opposition for changing the policy would be like ;-)

I vaguely remember hearing positive things about py.test.  I haven't
looked into it myself.  I agree with Tim that until py.test was in the
stdlib, it's not practical to use.  I'm -1e6 on it going into 2.5. :-)
 No opinion (yet) on 2.6.

It would suck to have 2 testing frameworks in the stdlib though.
unittest would really need to be deprecated.  I'm not sure the pain is
worth it.  If there was a way to enhance unittest to be more pythonic
(perhaps like py.test?), that would be just fine with me.

n