<div dir="ltr"><div class="markdown-here-wrapper" id="markdown-here-wrapper-64986" style><p style="margin:1.2em 0px!important">I prefer approach (3), the main reason being I don&rsquo;t ship my tests. Another reason is because my tests typically have many more dependencies than the code (e.g., pytest, mock, etc.). And if you ship it with your package, users should be able to import and run it. I haven&rsquo;t worked on large source trees like Bloodhound or Mailman, though.</p>


<p style="margin:1.2em 0px!important">It&rsquo;s possible to tell Setuptools not to include test modules or packages if you use approach (1) or (2), but I think it&rsquo;s a hassle for little return. I simply mirror my package hierarchy in a <code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;display:inline">tests/</code> hierarchy &mdash; one test module per one code module.</p>


</div><div></div></div><div class="gmail_extra"><br clear="all"><div><div><br></div><div>--</div><div>Sean Fisk</div></div>
<br><br><div class="gmail_quote">On Thu, Feb 27, 2014 at 7:30 PM, John Wong <span dir="ltr">&lt;<a href="mailto:gokoproject@gmail.com" target="_blank">gokoproject@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir="ltr"><br><div class="gmail_extra"><br>On Thu, Feb 27, 2014 at 6:51 PM, Olemis Lang <span dir="ltr">&lt;<a href="mailto:olemis@gmail.com" target="_blank">olemis@gmail.com</a>&gt;</span> wrote<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">


<div><div><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div class="gmail_quote"><div class=""><div><br></div><div>The structure is like this&nbsp;</div><div><br></div><div>+ /trunk</div><div>| +-- bloodhound_dashboard</div>


<div>| | &nbsp; &nbsp;+-- setup.py</div><div>| | &nbsp; &nbsp;+-- bhdashboard</div>

<div>| | &nbsp; &nbsp;&nbsp; &nbsp; &nbsp;+-- ... plugin source code with sub packages ...</div><div>| | &nbsp; &nbsp; &nbsp; &nbsp; +-- tests</div><div>| | &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;+--- ... test code ...</div></div><div><div>&nbsp;</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">


<div dir="ltr"><div><div>I believe this means tests is also included in the package installation (when you run setup.py)<br>

</div></div></div></blockquote><div><br></div></div><div class=""><div>no, afaict 
those folders are ignored in setup.py pkg defintion . For multiproduct 
module the separation is more obvious . Harder to see for trac source 
tree .</div>
<div><div>&nbsp;</div></div></div></div></div></div></div></div></div></blockquote><div><br></div>I know this is not the right place to discuss this, but are you sure? I just cloned and did a test.<br><br>&gt;&gt;&gt; from bhdashboard.tests import test_report<br>


In fact, bloodhound_multiproduct is the only package that has tests/ next to setup.py. I think all the points you in comment 3 (<a href="https://issues.apache.org/bloodhound/ticket/770#comment:3" target="_blank">https://issues.apache.org/bloodhound/ticket/770#comment:3</a>) are valid.<br>


<br></div><div class="gmail_extra">To back up your argument:&nbsp; see <a href="http://www.ianbicking.org/docs/setuptools-presentation/" target="_blank">http://www.ianbicking.org/docs/setuptools-presentation/</a>&nbsp; slide 20 though.<br>

</div><div class="gmail_extra">
<br></div><div class="gmail_extra">But sadly, a lot of projects choose to put tests as a subpackage. i suspect this surprising outcome has to do with <a href="http://guide.python-distribute.org/example.html?highlight=test" target="_blank">http://guide.python-distribute.org/example.html?highlight=test</a><br>


</div><div class="gmail_extra">For example, Pyramid does it: <a href="https://github.com/Pylons/pyramid/tree/master/pyramid" target="_blank">https://github.com/Pylons/pyramid/tree/master/pyramid</a><br></div><div class="gmail_extra">

Django webframework users also tend to write tests under each app.<br>
</div><div class="gmail_extra">mysite/user/tests<br>mysite/forum/tests<br><br></div><div class="gmail_extra">etc.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">So why would anyone choose to make tests a subpackage?<br>


</div><div class="gmail_extra">setuptools provides another command called tests (python setup.py tests). See <a href="http://stackoverflow.com/questions/4734292/specifying-where-to-install-tests-require-dependecies-of-a-distribute-setuptoo" target="_blank">http://stackoverflow.com/questions/4734292/specifying-where-to-install-tests-require-dependecies-of-a-distribute-setuptoo</a><br>


I can even hook this up with nose and pytest. Therefore, people who choose to make tests a submodule can separate test dependencies from project dependencies. That&#39;s probably the #1 defense.<br><br></div><div class="gmail_extra">


Ultimately, it&#39;s down to the core developers to side with you or not. I think it makes sense NOT to ship tests during runtime. I don&#39;t know why I would ever want to open my interpreter and knowing I could import package.tests. That doesn&#39;t makes sense. I am not sure if there is a way to tell setuptools don&#39;t make X directory a subpackage or not. Probably there is.<span class="HOEnZb"><font color="#888888"><br>


<br></font></span></div><span class="HOEnZb"><font color="#888888"><div class="gmail_extra">John<br></div></font></span></div>
<br>_______________________________________________<br>
testing-in-python mailing list<br>
<a href="mailto:testing-in-python@lists.idyll.org">testing-in-python@lists.idyll.org</a><br>
<a href="http://lists.idyll.org/listinfo/testing-in-python" target="_blank">http://lists.idyll.org/listinfo/testing-in-python</a><br>
<br></blockquote></div><br></div>