[TIP] Unittest Changes

[C. Titus Brown]

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?

cheers,
--titus
-- 
C. Titus Brown, ctb at msu.edu