[prev in list] [next in list] [prev in thread] [next in thread] 

List:       python-distutils-sig
Subject:    Re: [Distutils] [TIP] Guidelines for where to put tests & how to
From:       "P.J. Eby" <pje () telecommunity ! com>
Date:       2010-02-26 20:53:21
Message-ID: 20100226205324.12BB13A406A () sparrow ! telecommunity ! com
[Download RAW message or body]

At 02:27 PM 2/26/2010 -0500, Olemis Lang wrote:
>test_suite is ( supported | introduced | defined ) by
>setuptools.comand.test.test class
>
> > Is it required to be a
> > callable
>
>yep

No.  test_suite is to be an object recognized by the test_loader as 
convertible to a unittest TestSuite.  For example, a module, TestCase 
subclass, etc.

You are probably thinking of the test_runner option, not test_suite.



>test command performs test discovery (as a last recourse AFAICR, /me
>cc-ing to P.J. Eby because probably he has further updates ;o) using a
>loader: setuptools.comand.test.xxx

Setuptools' test loader will scan modules and packages, but you still 
have to tell it where your top-level test package or module is.  (The 
test_suite.)


>BTW, I am strongly -1 for using the discovery protocol introduced in
>2.7 (AFAICR), specially because it collides with test_suite and many
>other arguments ... so it would be very nice when defining packaging
>conventions, layout ... not to enforce the use of that protocol, so
>that if another discovery is used then it could still be compatible
>with the more abstract good practices. (all this said from my selfish
>position, I confess)

I'm not sure what you're talking about here; I'm not much in the loop 
for what's going on with distutils updates, and even more so for 
unittest updates.

_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
[prev in list] [next in list] [prev in thread] [next in thread]