[TIP] unittest2, distribute, and doctests

[Michael Foord]

On 07/06/2010 22:43, Barry Warsaw wrote:
> Hey guys, I have a few quick questions about unittest2.  Apologies if these
> have been discussed before.
>
> Distribute adds the ability to run 'python setup.py test' by including the
> `test_suite` keyword to your setup().  What's the best way to integrate
> unittest2 and distribute to enable the former to do test discovery when run
> via the setup.py?
>
>    

I'm afraid that I don't know how to do that *currently*, given that I'm 
not a user of setuptools or distribute.

The *plan* is for distutils2 to include a test command that will 
*default* to test discovery if unittest2 is available or Python 2.7+ is 
being used.

http://bugs.python.org/issue8324
> `python setup.py test` supports a -m and -s option to filter (minimally) the
> tests that are run.  Can unittest2's richer command line options be supported?
> (This may be more of a distutils/setuptools/distribute question.)
>
>    

My understanding is that some of the discovery options will be 
configurable. I defer to Tarek and his GSOC team who are actually 
implementing for a definitive answer though.


> unit2 -p takes shell globs, but I really like zope.testrunner's regexp-based
> filters.  Any chance unittest2 will support something like that?

Hmmm... as an intermediate step I exposed the filename matching as a 
method on the TestLoader (_match_path) so that subclasses can be 
overridden. After the release of Python 2.7 my next goal is to make 
unittest extensible and file matching would be one of the extension 
points (so regex file matching would be trivially easy to provide as an 
extension).

I'm not sure about building it into unit2 / unittest itself though. Can 
you give me an example of something you want to do that requires regexes 
and doesn't work with shell globs.


> One of the
> reasons I like zope's test discovery is because it works much better with
> doctests.  E.g. I can do (after a buildout):
>
>      % bin/test -vv -t using
>
> and it will only run my using.txt doctest.  Note that I have a test_docs.py
> module that does individual .txt doctest discovery, wrapping each one in a
> DocFileSuite with appropriate optionflags, and setUp.  IWBNI unittest2
> eventually grew better support for doctests.
>
>    

I'd be interested in hearing how it should grow that support. Again, it 
is something ripe for being implemented as an extension - but I'd like 
to see better doctest support in the test runner.

> Is it intentional that a module's load_tests() not called when unit2 -p is
> used?
>    

No - that is definitely not intentional and from the code I can't see 
how that is possible, nor can I reproduce it. Can you provide a minimal 
repro? The way load_tests is called from __init__.py is a bit weird 
though and I'm not happy with it. Perhaps this is tripping you up?

All the best,

Michael


> Cheers,
> -Barry
>    
>
>
> _______________________________________________
> testing-in-python mailing list
> testing-in-python at lists.idyll.org
> http://lists.idyll.org/listinfo/testing-in-python
>    


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies ("BOGUS AGREEMENTS") that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idyll.org/pipermail/testing-in-python/attachments/20100607/32e7419c/attachment.htm>