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

C. Titus Brown ctb at msu.edu
Sat Feb 27 11:48:37 PST 2010


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?

We should put something in the Hitchhiker's Guide to Packaging, which is
for 2.4+.  So far Tarek has avoided putting in "just use distutils2"; I doubt
that's going to change because the testing community wants it to, and I
think it'd be a bad idea anyway.

Some glorious day in the future everyone will be using Python 3.3 and we
can drop support for Python 2.6.  Until then, IMO it's not OK to have a
convention that relies on 3rd-party packages, however blessed they be.

>>> With the load_tests protocol your test module or package (specified by
>>> tests) can return a unittest compatible suite even if tests are actually
>>> run under-the-hood with another framework. unittest will then only be
>>> used for reporting results.
>>>      
>> OK, this still seems a bit restrictive; as we've discussed, unittest is
>> full of snakes that won't ever (or at least soon) be cleared out completely,
>> for the sake of backwards compatibility.  So I'd like to avoid enshrining
>> load_tests as a convention.
>>    
> load_tests is already a convention. This particular hook allows you to  
> interoperate with unittest whilst avoiding most of the snakes. If you  
> have *specific* problems with this approach then I'd like to hear about  
> them. :-)

I don't like or really understand the unittest test running and reporting
tools.  Maybe it's a problem that can be solved with documentation or
just by LARTing myself.

I'll go take a look.

> Anyway, regardless of whether you think it is a good thing to use it or  
> not this hook already exists in the new and improved unittest and we  
> certainly can't *stop* people using it this way if they want.

No, and I'm certainly not trying to do so!  I'm really not into B&D programming
anyway.  I do think that it's a great idea for Python testing sub-community,
which has a lot of accumulated wisdom and (often bad) experience, to plant
a stake in the sand and say "doing things this way has benefits that you won't
appreciate until you're a year into your project!"

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



More information about the testing-in-python mailing list