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

Jesse Noller jnoller at gmail.com
Tue Jul 27 10:08:46 PDT 2010

On Tue, Jul 27, 2010 at 10:04 AM, Barry Warsaw <barry at python.org> wrote:
> On Jul 27, 2010, at 03:37 PM, Marius Gedminas wrote:
>>On Tue, Jul 27, 2010 at 01:32:20PM +1000, Ben Finney wrote:
>>> The trick then becomes management of the build script so that the
>>> install step does *not* deploy the tests. Which requires thinking of
>>> one's package as a package to be deployed, even though you're
>>> deploying it in source form. From that point, it's a matter of
>>> learning about Distutils and all the rest.
>>Other than wasting a bit of disk space, what are the downsides of
>>installing the tests?
> To me, nothing.  In fact I think there's a lot of upside to including the
> tests.  It helps instill confidence in the installed version of the package,
> and it can provide a level of documentation.  I also have in mind a
> Python-wide test infrastructure that would install as many packages as
> possible, run the tests, and gather health metrics for each package, possibly
> indicating the status on the Cheeseshop.
> +1 for including the tests by default.

Agreed 100x with Barry - additionally, tests are sometimes *better*
then documentation for figuring out how to use, or the actual behavior
of something.


More information about the testing-in-python mailing list