[TIP] Unittest Changes

Jonathan Lange jml at mumak.net
Mon Jul 21 17:05:30 PDT 2008

On Mon, Jul 21, 2008 at 11:35 PM, Michael Foord
<fuzzyman at voidspace.org.uk> wrote:
> Jonathan Lange wrote:
>> On Mon, Jul 21, 2008 at 7:16 AM, Michael Foord
>> <fuzzyman at voidspace.org.uk> wrote:
>>> Unless someone beats me to it I'm intending to work on some improvements
>>> to unittest after I have finished "IronPython in Action", which
>>> realistically will be a couple more months.
>> Hi Michael,
>> I've already started a project along these lines, temporarily called
>> pyunit3k:
>>    http://launchpad.net/pyunit3k
>> I haven't announced it until now because the name sucks and because
>> it's test coverage is still rather poor. I would love it if you could
>> take a look at it and tell me what you think.
>> The aim is to incorporate improvements to unittest that have stood the
>> test of time in real projects, rather than to come up with blue-sky
>> features.
> Right - although virtually every project I've worked on with unittest had
> ended up with an ad-hoc test collection mechanism, so I think the
> 'discover_tests' features I've discussed are prima-facie needed.
> It looks like Twisted and Bzr both have prior-art in these areas.

Agreed. I'd be happy with having some sort of test discovery thing in
stdlib, as long as it was itself thoroughly tested. I'd be happier
still if it was derived from some of this prior art.

> Great to see some movement, and when I get time free to work on this I'll
> have a look at what you've done with pyunit3k. Are you targeting Python 2.7
> as well?

At the moment I'm writing all of it for Python 2.4, because that's
what Bazaar and Launchpad both use. It's not a fork of unittest.py,
just extensions.

> I've never had a need for per-module / per-class cleanup methods myself. I
> tend to prefer creating needed resources by decorating test-methods, even if
> this means creating them 'per-test'. As such I'm not so convinced about
> 'addCleanup' etc.

To be clear, addCleanup is not for per-class or per-module cleanup,
it's for cleanup at the end of a test for dynamically created

> In the end if these changes are to go back into unittest (which is my goal)
> then it will have to go through a PEP anyway.

Yes. I'm not personally concerned about the changes going back into
unittest—Twisted still supports Python 2.3—but agree that that's where
the changes should go.


More information about the testing-in-python mailing list