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". Regards, Thomas Güttler -- http://www.thomas-guettler.de/ _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig