[TIP] including tests in packages, or not
C. Titus Brown
ctb at msu.edu
Sun Sep 13 19:08:31 PDT 2009
On Sun, Sep 13, 2009 at 10:07:14PM -0400, Jesse Noller wrote:
-> 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.
-> 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.
Ahh, good point!
C. Titus Brown, ctb at msu.edu
More information about the testing-in-python