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

[C. Titus Brown]

On Fri, Feb 26, 2010 at 09:53:41PM +0000, Michael Foord wrote:
> On 25/02/2010 05:01, C. Titus Brown wrote:
>> Hi all,
>>
>> here at PyCon there have been a lot of packaging discussions, so I thought
>> I'd spend a bit of time outlining some suggestions for where to put
>> tests and how to run them.  It's been a bit of a thorn in the side of
>> (among other things) continuous integration systems that there's no
>> standard way to run Python tests... so let's fix that!
>>
>> I've produced a simple draft proposal&  example where you put your unit tests
>> under a package dir, somepackage/tests/.
>>
>> You can run these tests with
>>
>>    % python -m somepackage.tests.run
>>
>> and you can also do (if setuptools/distribute is installed)
>>
>>    % python setup.py test
>
> If you're happy to depend on distutils2 and unittest2 then very soon  
> there will be a standard "setup.py test" command that will continue to  
> work with future versions of Python. It will probably default to  
> unittest test discovery but allow you to provide a specific 'tests'  
> argument (either a module or suite) and a 'testrunner' (test_runner ?)  
> argument to specify a non-unittest runner if needed (testrunner defaults  
> to unittest.TextTestRunner, well actually unittest2.TextTestRunner).

Yes, but it doesn't specify how to run the tests in situations where
setup.py isn't available (e.g. post-install).  The distro packaging folk
like that idea, as do I.

> FWIW I would rather see ponybuild use distutils2 / unittest2 (i.e. the  
> recommended [1] community tools), but I understand your reluctance to  
> take a dependency on anything other than a single script on the client  
> side. A bootstrap script for installing dependencies would be one way  
> round this.

A solution that involves complicating things is not so good; one reason
why the stdlib is so awesome is that it's always there!

:)

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