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

Alfredo Deza alfredodeza at gmail.com
Tue Jul 27 09:07:33 PDT 2010


On Tue, Jul 27, 2010 at 10:42 AM, holger krekel <holger at merlinux.eu> wrote:

> hi Alfredo, all,
>
> On Mon, Jul 26, 2010 at 20:16 -0400, Alfredo Deza wrote:
> > A few weeks ago in our local Python meeting someone mentioned what a drag
> > was to (most of the time) have to download
> > the source for a package they have just installed to run the tests
> because
> > the 'test(s)' directory was not included at the time
> > of installation.
> >
> > Some packages include them (like unittest2) and some (most?) don't.
> >
> > What do you guys feel about including the test directory within your
> package
> > so it is included at the time of installation?
> >
> > I'm gearing towards including them, but wanted to hear your opinion about
> > it.
>
> To me there are pro's and con's.  These days i like to put my tests
> external to a package, especially if they are higher-level or functional
> tests.  This also allows to run the same tests against different versions
> of a package which i sometimes use for testing cross-version compatibility.
> The latter is not easy with package-inlined tests.
>
> Having said that i would like to have a way to generically
> test any installed package (including C-extensions where
> test-inlined-into-package is not really possible).   I rather
> ponder specifying a test-url such that a tool can go to installed
> packages, download the specified tests and run them, maybe even reporting
> them back somewhere.
>
> I can see how that could be a problem.

But not having consistency (or a guideline/best practice) for having (or
not) tests within a package
it would be difficult to implement the test-url approach.

What happens when network access is restricted? This would severely affect
the way any test-grabbing/reporting could happen.

What about having 2 sets of tests? the integration and high-level tests can
still be outside the package while everything else that would
not interfere could be "inline"



> best,
> holger
>
> >
> > Thanks,
> >
> >
> > Alfredo
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idyll.org/pipermail/testing-in-python/attachments/20100727/e0841b3b/attachment.htm>


More information about the testing-in-python mailing list