<br><br><div class="gmail_quote">On Tue, Jul 27, 2010 at 10:42 AM, holger krekel <span dir="ltr"><<a href="mailto:holger@merlinux.eu">holger@merlinux.eu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
hi Alfredo, all,<br>
<div><div></div><div class="h5"><br>
On Mon, Jul 26, 2010 at 20:16 -0400, Alfredo Deza wrote:<br>
> A few weeks ago in our local Python meeting someone mentioned what a drag<br>
> was to (most of the time) have to download<br>
> the source for a package they have just installed to run the tests because<br>
> the 'test(s)' directory was not included at the time<br>
> of installation.<br>
><br>
> Some packages include them (like unittest2) and some (most?) don't.<br>
><br>
> What do you guys feel about including the test directory within your package<br>
> so it is included at the time of installation?<br>
><br>
> I'm gearing towards including them, but wanted to hear your opinion about<br>
> it.<br>
<br>
</div></div>To me there are pro's and con's. These days i like to put my tests<br>
external to a package, especially if they are higher-level or functional<br>
tests. This also allows to run the same tests against different versions<br>
of a package which i sometimes use for testing cross-version compatibility.<br>
The latter is not easy with package-inlined tests.<br>
<br>
Having said that i would like to have a way to generically<br>
test any installed package (including C-extensions where<br>
test-inlined-into-package is not really possible). I rather<br>
ponder specifying a test-url such that a tool can go to installed<br>
packages, download the specified tests and run them, maybe even reporting<br>
them back somewhere.<br>
<br></blockquote><div>I can see how that could be a problem. </div><div><br></div><div>But not having consistency (or a guideline/best practice) for having (or not) tests within a package</div><div>it would be difficult to implement the test-url approach.</div>
<div><br></div><div>What happens when network access is restricted? This would severely affect the way any test-grabbing/reporting could happen.</div><div><br></div><div>What about having 2 sets of tests? the integration and high-level tests can still be outside the package while everything else that would</div>
<div>not interfere could be "inline"</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
best,<br>
holger<br>
<br>
><br>
> Thanks,<br>
><br>
><br>
> Alfredo<br>
<div><div></div><div class="h5"><br></div></div></blockquote></div>