[TIP] including (or not) tests within your package

Andrew Bennetts andrew at bemusement.org
Tue Jul 27 18:13:52 PDT 2010


Ben Finney wrote:
> Marius Gedminas <marius at gedmin.as> writes:
> 
> > Other than wasting a bit of disk space, what are the downsides of
> > installing the tests [along with the rest of the package]?
> 
> They would thereby become part of the *public* interface for the
> package. I don't want that implied promise; the test suite is subject to
> arbitrary unannounced change or removal.

Surely you don't consider every importable name to be part of the public
interface for a package?

If implied publicness of the API is's your concern, call your tests
subpackage “_tests”.  Or put “NOT PUBLIC API; DO NOT USE” at the top of
the docstring for that package, or whatever convention you usually use
to signal to your API clients which parts aren't public.

> They're for use while developing (hence part of the source), not in their
> deployed location (hence *not* part of the binary package).

What about packages that build on your packages?  e.g. it's common for
tests for bzr plugins to use some test infrastructure from bzrlib.tests
in their own test suite.  Ditto for applications (or libraries) built on
Twisted.

Do you provide a foolib-tests (or maybe foolib-dev) binary package
alongside the foolib package?  Or provide a public foolib.test_support
module that has all the bits you expect others to need?   [They both
seem like plausible answers to me, but I'm curious to hear if someone
has experience with these approaches.]

Also, there is some value to enabling users to run tests in their
deployed environment, where they may have a unique combination of
dependency versions, system configuration, etc.

-Andrew.




More information about the testing-in-python mailing list