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

[C. Titus Brown]

On Fri, Feb 26, 2010 at 02:52:49PM -0500, Olemis Lang wrote:
> On Fri, Feb 26, 2010 at 2:36 PM, Michael Foord
> <fuzzyman at voidspace.org.uk> wrote:
> > On 26/02/2010 19:27, Olemis Lang wrote:
> >>
> >> [snip...]
> >>>
> >>> Why not just:
> >>>
> >>> ? ? tests='somepackage.tests'
> >>>
> >>>
> >>
> >> Better explicit than implicit : what are `tests` ? test_suite is a test
> >> suite !
> >>
> >> so IMHO -1
> >>
> >
> > Tests are a test package. What if you want to specify something other than a
> > test suite?
> 
> test_module
> 
> ;o)
> 
> >>> Or even default to test discovery?
> >>
> >> 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
> >
> > I'd rather follow up with Tarek (cc'd) as the lead maintainer of both
> > distribute (the maintained fork of setuptools) and of distutils(2).
> 
> but I was talking about setuptools and the precision was mainly for
> the loader that performs discovery and features in setuptools 0.7.x
> trunk, I really don't follow `distribute`, so ... (besides PJE has
> always had the virtue -at least according to my experience ;o)- of
> providing the right comment at the right time, thus saving me from
> chaos ;o)

Be that as it may, we're doing our best to convert this whole thing into either
a PEP-driven process or at least a documented good-enough practice.  PJE is
welcome to participate in both!

I *really* want to present Tarek and the distutils folk with a sensible,
minimalistic convention that doesn't break anything (and could even be
compatible with most things that are out there).  Then  PJE can update
setuptools to do the Right Things, distutils2 can handle it, etc.

> >> BTW, I am strongly -1 for using the discovery protocol introduced in
> >> 2.7 (AFAICR), specially because it collides with test_suite
> >
> > You'd rather not use a unittest supported protocol because it clashes with
> > an unsupported protocol?

I agree with Olemis here -- let's try not to actively break setuptools unless
there's a good reason.  It's very widely deployed and large parts of it are
serving as the basis for distutils2, from what I understand.

> >> ?and many
> >> other arguments ...
> >
> > Can you be specific?
> 
> Nevermind, everything I've said about the subject was just like ?dust
> in the wind? so, with all respect, I won't follow ...

<sigh>

> Well, unittest invokes `suite` callable by default whereas test
> command invokes `test_suite`. So basically it's a duplicate convention
> AFAICS (CMIIW). If some type of reconciliation is going to happen
> that'd be good, but :

collision != redundancy.

If 'suite' vs 'test_suite' is the issue, then we could update setuptools to
support what's in the stdlib, and/or create a new standard mechanism in
distutils2.  That's redundancy and it's easy to handle.

If 'suite' meant DIFFERENT THINGS to setuptools and unittest2, then we'd
have a problem...

>   - I don't what's the most popular style

Hence we are asking on this list ;)

>   - the fact is that more similar redundant conventions
>     are emerging these days, so ...

Yes, well, let's see if we can smother them in their crib with a goat, yes?

And Olemis, you're reaching your ... quota again ;).

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