[TIP] including tests in packages, or not

[Jesse Noller]

On Sun, Sep 13, 2009 at 9:55 PM, C. Titus Brown <ctb at msu.edu> wrote:
> Hi all,
>
> I'm whipping together a quick little tagging Web site for an initiative,
> and I thought I'd try putting all of my tests in the package itself --
>
>    tagnabbit/
>       __init__.py
>       ...
>       tests/
>
> nose still finds them there, of course, and with the new import
> mechanisms I don't have to do any of my usual path manipulations to get
> the tests to import the right package ahead of other things in my
> sys.path -- I can just do
>
>    from .. import foo.py
>
> to get at 'tagnabbit.foo', for example.
>
> Another advantage is that I can install the tests with tagnabbit, which
> is nice.
>
> So, so far I'm happy with this layout.  What am I missing?
>
> --
>
> My normal layout is to put the tests at the same level as the package in
> my dev dir, e.g.
>
>    tagnabbit/  -- package
>      __init__.py
>    tests/
>
> where I usually munge sys.path to get the import to load my dev version
> of tagnabbit as opposed to whatever might be installed.
>
> thanks,
> --titus
> --
> C. Titus Brown, ctb at msu.edu

I'm actually doing this now for some code I'm working on. Putting the
*unit* tests down there helps me mentally split between units, and
higher level functional tests (which might or might not just be for my
project).

Also, if people *really* want, they can import "foobar.test" and gain
access to specific things I've put in there to help them potentially
tests stuff they've built on top of it.

jesse