[TIP] including tests in packages, or not

Jesse Noller jnoller at gmail.com
Sun Sep 13 19:07:14 PDT 2009

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

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.


More information about the testing-in-python mailing list