[Distutils] Where should I put tests when packaging python modules?

Thomas Güttler guettliml at thomas-guettler.de
Fri Oct 9 19:44:23 CEST 2015

Am 07.10.2015 um 01:14 schrieb David Wilson:
> On Tue, Oct 06, 2015 at 09:51:01AM +0200, Antoine Pitrou wrote:
>> They should be inside the module. That way, you can check an installed
>> module is ok by running e.g. "python -m mypackage.tests". Any other
>> choice makes testing installed modules more cumbersome.
> As Donald mentioned, this doesn't work in the general case since many
> packages ship quite substantial test data around that often doesn't end
> up installed, and in other cases since the package requires significant
> fixture setup or external resources (e.g. running SQLAlchemy tests
> without a working database server would be meaningless).

Should work with a temporary sqlite db.
> The option of always shipping test data as a standard part of a package
> in a vein attempt to always ensure it can be tested (which is not always
> likely given the SQLAlchemy example above) strikes me as incredibly
> wasteful, not from some oh-precious-bytes standpoint, but from the
> perspective of distributing a Python application of any size where the
> effects of always shipping half-configured test suites has increased the
> resulting distribution size potentially by 3 or 4x.
> https://github.com/bennoleslie/pexif is the first hit on Google for a
> module I thought would need some test data. It's actually quite
> minimally tested, yet already the tests + data are 3.6x the size of the
> module itself.
> I appreciate arguments for inlining tests alongside a package in order
> to allow reuse of the suite's functionality by consuming applications'
> test suites, but as above, in the general case this simply isn't
> something that will always work and can be relied on by default.
> Is there perhaps a third option that was absent from the original post?
> e.g. organizing tests in a separate, optional, potentially
> pip-installable package.

Yes, this third way is plausible. I guess there is even a fourth way.

The question remains: If a new comer asks you "How to package my
python code and its tests?", there should be one default answer
which works for 80% of all cases.

I think the confusion gets worse by creating new public accessible
repos which explain "Hey that's my way to package stupid simple
python code".

  Thomas Güttler


More information about the Distutils-SIG mailing list