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

[Tim Peters]

>>> Author: martin.blais
>>> Date: Fri Jun  2 15:03:43 2006
>>> New Revision: 46603
>>>
>>> Modified:
>>>    python/trunk/Lib/test/test_struct.py
>>> Log:
>>> Fixed struct test to not use unittest.

[Neal Norwitz]
>> Shoot, I had hoped you would go the other way and convert all the old
>> test cases to use unittest. :-)

[Thomas Wouters]
> Heh, my reaction was both "huh?" and "yay" at the same time. I thought
> unittest was still preferred for the stdlib testsuite?

That or doctest.  What's definitely unwanted now is the original style
of test that compares the whole test's output to an expected-output
file in Lib/test/output/.  Those can be horrid to figure out when they
go wrong, and don't check at all when running regrtest with -v.

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.

> 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

I haven't used py.test, but I'm sure it's not used at all in Python's
test suite.  Don't know what "test-generators" refers to --  Python's
Lib/test/test_generators.py is a doctest.

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

py.test doesn't ship with Python, so we certainly can't use py.test in
Python's standard test suite unless/until py.test does ship with
Python.