<p>On Jul 26, 2010 8:19 PM, "Alfredo Deza" <<a href="mailto:alfredodeza@gmail.com" target="_blank">alfredodeza@gmail.com</a>> wrote:</p><p>> 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></p><p>Speaking from my experience from framework development the general consensus is that test-in-packages make things more complicated, as complex packages tend to have additional test dependencies and sometimes you need a special setup for some of them and tests just bloat the userspace if they are distributed together. </p>
<p>Personally other than running on other platforms/setups the core team lacks I don't see any benefit from having the tests in package. At worst of any of those tests fails under some obscure situation they should be catch by the build/release process.</p>
<p>And if you as an end user are submitting a patch and want to run the test, I expect you to have a fork or checkout, instead of a plain old patch which means you are downloding the whole thing anyway.</p><p>My 0.02cents</p>
<p></p>