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

Olemis Lang olemis at gmail.com
Fri Jul 30 05:01:08 PDT 2010

On Thu, Jul 29, 2010 at 9:49 PM, David Stanek <dstanek at dstanek.com> wrote:
> On Thu, Jul 29, 2010 at 3:54 PM, Olemis Lang <olemis at gmail.com> wrote:
>> On Thu, Jul 29, 2010 at 2:34 PM, Michael Foord
>> <fuzzyman at voidspace.org.uk> wrote:
>>> On 29/07/2010 20:29, Éric Araujo wrote:
>>>> 0.02 €: As a user, I prefer not to have tests and extensive docs per
>>>> default. I like installing an OS and lots of useful packages on very
>>>> small hard drives/partitions. I’m biased, since I use OS packages that
>>>> are already built and tested for my setup.
>>> Right - horses for courses. As a user it frustrates the *heck* out of me
>>> when a package doesn't include documentation, especially if I install it and
>>> then try to use it when I no longer have an internet connection. I always
>>> trust a package a lot more if it comes with tests, even if I don't actually
>>> run them...
>> It comes with tests but not inside the same package . I'm sure that if
>> somebody considers all the instances of Apache running public Internet
>> sites (restrict the scope, on Debian | Ubuntu ;o) the percent with
>> apache-doc installed will be almost 0% ... or is it that you use to
>> install apache-doc in each and every such server so that you'll be
>> able to read the docs when ... when ?
>> What's the difference between having tests inside the package and
>> having a separate pkg for that . I mean, in the end you'll always be
>> able to test it , and that's what really matters (or not ?)
> As a package developer I find it very convenient to have docs and
> tests directories at the same level as my source code.

In your VCS and sdists , yes . Do you really need all that in the
location where the package will be deployed | installed (production
environment) ? Why ?

> Does it really
> matter if you get a couple extra K of date when you install the
> package?

Probably this is a matter of flavors . The fact is that I've not seen
yet (or probably skipped ...) a strong reason (besides my current
laziness ;o) in favor of *always* including tests inside a package
prepared to run in production systems . Probably others find no
reasonable arguments for not including'em (and I understand that , I'm
lazy too !!! ) .

I prefer the thinking of the old school stating that every byte
matters . For instance (and this is OT ;o) why would I install MS VS
2k10 to develop certain kinds of .NET apps (and «waste» > 2GB in my
HDD among other PITAs ) if I can do exactly the same with SharpDevelop
(~40MB) ? Most of the time I'm in favor of using resources as
efficiently as possible , 'cause they are scarce (and we have to be
responsible and save the planet :) ... ) .

Specially in this case , what's the point of including tests in
ready-to-use packages over having a separate package for including
tests ?

PS: There is always a difference between what *SHOULD* be done and
what *IS ACTUALLY* done ;o)



Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:

More information about the testing-in-python mailing list