[TIP] Unittest Changes

Michael Foord fuzzyman at voidspace.org.uk
Mon Jul 21 06:52:53 PDT 2008


C. Titus Brown wrote:
> On Mon, Jul 21, 2008 at 02:47:22PM +0100, Michael Foord wrote:
> -> C. Titus Brown wrote:
> -> >On Mon, Jul 21, 2008 at 02:35:58PM +0100, Michael Foord wrote:
> -> >-> Jonathan Lange wrote:
> -> >-> 
> -> >-> 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.
> -> >
> -> >How difficult (and controversial) do you think it would be to provide a
> -> >"test hook" that could reside in some top-level place (setup.py, or
> -> >module __init__, or something) that would let you override
> -> >discover_tests with your own evil algorithm?
>
> [ ... ]
>
> -> Can you suggest how it might be implemented in unittest?
> -> 
> -> If it can be done *cleanly* then it shouldn't be too controversial.
> -> 
> -> If a  module has this attribute:
> -> 
> ->    test_suite = 'something.else'
> -> 
> -> Then how should unittest invoke 'something.else' ? (And must 
> -> 'something.else' then present a suite compatible with a unittest 
> -> TestRunner ?)
>
> These are good questions to which I do not have an answer :).  I don't
> know how hard it would be to layer a TestRunner-compatible interface on
> top of py.test tests, in particular; it may make sense to go with
> something simpler.
>
> -> I'm not 100% convinced that this is the job of unittest, but if it can 
> -> be done cleanly in a way that is already compatible with nose then it 
> -> could be cool.
>
> I don't think it has to be compatible with nose or py.test -- they are
> fast-moving frameworks compared to stdlib and they can adapt!  The
> problem is to get something *into Python itself* so that we can have
> standard ways of specifying these things.
>
> Is it the job of unittest?  Dunno.  It should be in the stdlib IMO;
> where else?
>   

All we really need is a compatible way of collecting the *results* 
(delegating *running* the tests to the framework they belong to). I 
wonder if a minimal required API for that can be hammered out that would 
be acceptable to the nose guys at least.

Michael
> cheers,
> --titus
>   


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/
http://www.trypython.org/
http://www.ironpython.info/
http://www.resolverhacks.net/
http://www.theotherdelia.co.uk/




More information about the testing-in-python mailing list