<div dir="ltr"><br><div class="gmail_extra">Hi !<br>:)<br><br><div class="gmail_quote">On Thu, Feb 27, 2014 at 5:37 PM, Barry Warsaw <span dir="ltr"><<a href="mailto:barry@python.org" target="_blank">barry@python.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Feb 27, 2014, at 04:43 PM, Olemis Lang wrote:<br>
<br>
>Recently a discussion has started about the location of test modules<br>
>developed for Apache Bloodhound [1]_ .<br>
<br>
</div>Paraphrasing the old joke, if you ask 5 Python programmers you'll get 10<br>
opinions. :)<br>
<br></blockquote><div><br></div><div>yes , I know ... that's exactly one of the reasons why I started this thread , just to explore other people's ideas .</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In my capacity as Debian and Ubuntu developer, I've certainly seen at least<br>
all three of your variations in packages I've looked at. For my own software,<br>
I strongly prefer:<br>
<div class=""><br>
> 1. Our modified copy of Trac includes multiple test modules<br>
> i.e. one source code per-package all over across the whole hierarchy<br>
<br>
</div>I put a tests subpackage and a docs subpackage right under the subpackage that<br>
they are testing (or documenting <wink>). I do it this way, especially for<br>
big source trees like Mailman because I want the tests and docs to be as close<br>
to the code as possible. It makes it *way* easier to find the test for a<br>
specific module.<br>
<div class=""><br></div></blockquote><div><br></div><div>makes sense to me with unit tests only ...</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
>I'd rather prefer the option (3) because of the reasons I mentioned in<br>
>bh:comment:3:ticket:770 [2]_ which I repeat below :<br>
><br>
> - Having a single top-level tests module (as opposite to Trac's<br>
> scattered test modules)<br>
> is convenient considering the package test discovery code<br>
<br>
</div>I've gravitated toward nose2 for all my packages, and it has no problem with<br>
layout #1.<br>
<div class=""><br></div></blockquote><div><br></div><div>... but #1 seems more complicated when dealing with functional tests considering modules import-ed along the way .</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">
> - For code with functional + unit tests (i.e. quite often) I prefer to<br>
> write tests in a separate package hierarchy because :<br>
> * they should not be installed in production deployments<br>
<br>
</div>I personally don't care much about that. I think it doesn't harm anything to<br>
have the tests installed, and might even be useful for debugging. But I'm not<br>
philosophically opposed to omitting the tests from production code, and in<br>
some of the Debian packaging I've done, we relegate such test directories to a<br>
"-dev" package.<br></blockquote><div><br></div><div>Good point . However the Debian packaging system can do a number of install operations not available (afaik) in distutils / setuptools / distribute / pip ... package management ecosystem .</div>
<div>cmiiw</div></div><br>-- <br>Regards,<br><br>Olemis - @olemislc<br><br>Apache™ Bloodhound contributor<br><a href="http://issues.apache.org/bloodhound">http://issues.apache.org/bloodhound</a><br><a href="http://blood-hound.net">http://blood-hound.net</a><br>
<br>Blog ES: <a href="http://simelo-es.blogspot.com/">http://simelo-es.blogspot.com/</a><br>Blog EN: <a href="http://simelo-en.blogspot.com/">http://simelo-en.blogspot.com/</a><br><br>Featured article:<br><br><br>
</div></div>