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

[C. Titus Brown]

On Sat, Feb 27, 2010 at 08:00:48PM +0000, Michael Foord wrote:
> On 27/02/2010 19:48, C. Titus Brown wrote:
>> On Sat, Feb 27, 2010 at 07:37:54PM +0000, Michael Foord wrote:
>>    
>>> On 27/02/2010 19:32, C. Titus Brown wrote:
>>>      
>>>> So where our goals differ is that you want to define a new convention
>>>> going forward (2.7+, 3.3+) and I want to document some convention that's
>>>> "good enough"&   backwards compatible to 2.4.
>>>>        
>>> I will strongly argue, and suspect Tarek will agree, that the
>>> recommended practise for Python 2.4+ users is to use distutils2. That
>>> way they can use the conventions that will just-work (tm) in future
>>> versions of Python. distutils2 and unittest2 are both maintaining
>>> compatibility with Python 2.4 specifically so they can be used in this
>>> way.
>>>      
>> Humm, why isn't this style of test running:
>>
>>    % python -m somepackage.tests.run
>>
>> a good solution that removes the need for using distutils2 for 2.4+ users?
>
> Because it requires providing a run module that implements test  
> collection and running, which is very dull code to write and easy to get  
> wrong or fail to update as you add new tests.

This is an excellent point and I think should end this thread ;).

I really want to provide a convention that can be used out-of-the-box for
Python2.4+ stock distributions.  As part of my interest in defining a
convention, I will undertake to write documentation (for the HGTP, or wherever)
pointing out that wherever possible you should support newer conventions, and
providing simple boilerplate copy/paste code to support situations where you
cannot or don't want to rely on anything other than the stdlib.

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