<div dir="ltr"><br clear="all"><div>Recently a discussion has started about the location of test modules developed for Apache Bloodhound [1]_ . In its current form the code in /trunk includes three approaches :</div><div><br>
</div><div> 1. Our modified copy of Trac includes multiple test modules</div><div> i.e. one source code per-package all over across the whole hierarchy</div><div> 2. A single sub-module tests as a child of the source code top-level package</div>
<div> e.g. bhdashboard.tests , bhsearch.tests , bhrelations.tests , ...</div><div> 3. A separate top-level module for unit + functional tests in Bloodhound </div><div> Multiproduct plugin .</div><div><br></div>
<div>I'd rather prefer the option (3) because of the reasons I mentioned in bh:comment:3:ticket:770 [2]_ which I repeat below :</div><div><br></div><div> - 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</div><div> * it's not unittest package discovery but our own code relying </div><div> on setuptools (or equivalent) + pkg_resources<br>
- 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> * they might be packaged and distributed independently should they be<br>
run upon a given source tree to identify a certain issue , but then discarded<br> * in practice there might be no need to import top-level source tree<br> in order to import top-level test module and contained test code especially if</div>
<div> writing functional tests<br> - you'll need other dependencies instead e.g. [pypi:selenium] ,<br> [pypi:twill] , stdlid `xmlrpclib` ...<br> - and even for unit tests the top-level source package may always be<br>
imported and resources located with the help of `pkg_resources`<br></div><div><br></div><div>.. [1] <a href="https://issues.apache.org/bloodhound/ticket/770">https://issues.apache.org/bloodhound/ticket/770</a></div>
<div><br></div><div>.. [2] <a href="https://issues.apache.org/bloodhound/ticket/770#comment:3">https://issues.apache.org/bloodhound/ticket/770#comment:3</a></div><div><br></div><div>I found other references on the subject </div>
<div><br>.. [3] <a href="https://pytest.org/latest/goodpractises.html#choosing-a-test-layout-import-rules">https://pytest.org/latest/goodpractises.html#choosing-a-test-layout-import-rules</a></div><div><br>.. [4] <a href="http://stackoverflow.com/questions/5341006/where-should-i-put-tests-when-packaging-python-modules">http://stackoverflow.com/questions/5341006/where-should-i-put-tests-when-packaging-python-modules</a></div>
<div><br>.. [5] <a href="http://stackoverflow.com/questions/61151/where-do-the-python-unit-tests-go">http://stackoverflow.com/questions/61151/where-do-the-python-unit-tests-go</a></div><div><br></div><div>... but I'd like to know what's your opinion . All other recommendations based on previous experience will be welcome as well </div>
<div><br></div><div>Thanks in advance !</div><div><br></div>-- <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>