[TIP] Guidelines for where to put tests & how to package them

Michael Foord fuzzyman at voidspace.org.uk
Fri Feb 26 10:29:23 PST 2010


On 25/02/2010 07:03, Robert Collins wrote:
> On Wed, 2010-02-24 at 21:01 -0800, C. Titus Brown wrote:
>    
>> Hi all,
>>      
> ..
>    
>> Full source at http://github.com/ctb/SomePackage or downloadable
>> at
>>
>>     http://lyorn.idyll.org/~t/transfer/SomePackage.tar.gz
>>
>> Comments?  Thoughts?  Complaints?  Issues I missed?
>>      
> The boilerplate 'run' isn't needed.
>
>    

Well - the techniques you discuss below work for unittest based tests, 
will they automatically work for doctest tests? What about other test 
frameworks?

The advantage of having a run module that collects and runs the tests is 
that it is agnostic of which test runner is used (or at least allows the 
*user* to be agnostic, so long as they have the right dependencies 
installed anyway).

> Rather than 'get_suite' define 'test_suite', then
> $ trial somepackage.tests will 'just work'
> As will
> #actually, there is a bug open on this one:
> $ python -m unittest somepackage.tests.test_suite
>    
That bug is rejected:

http://bugs.python.org/issue7501

With the new unittest functionality (or unittest2 or the discover 
module) the correct way to do this is to define load_tests and do:

python -m unittest somepackage.tests.module_name
python -m unittest discover

Instead of module_name you can use the name of a suite or class or even 
individual test method.

Info on load_tests:

http://docs.python.org/dev/library/unittest.html#load-tests-protocol
> # but this works:
> $ python -m subunit.run somepackage.tests.test_suite
> $ python -m testtools.run somepackage.tests.test_suite
>
> If instead you define the load_tests hook, python 2.7 and 3.1 will work
> with
> $ python -m unittest somepackage   # discovery ftw
>
> In older pythons the discover module can do this for you as well, I
> don't know its command line interface tough.
>    

The discover module has the same command line interface for test 
discovery as unittest2 and the new unittest. The exception is that the 
'discover' subcommand is unneeded as test discovery is all that the 
discover module does.

More on the discover module (and its command line options) at:

http://pypi.python.org/pypi/discover

All the best,

Michael

> Cheers,
> Rob
>    
>
>
> _______________________________________________
> 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/20100226/c305fb1e/attachment.htm>


More information about the testing-in-python mailing list