[TIP] Fwd: Advice on location of tests modules

[Sean Fisk]

I prefer approach (3), the main reason being I don'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't worked on large source
trees like Bloodhound or Mailman, though.

It's possible to tell Setuptools not to include test modules or packages if
you use approach (1) or (2), but I think it's a hassle for little return. I
simply mirror my package hierarchy in a tests/ hierarchy -- one test module
per one code module.


--
Sean Fisk


On Thu, Feb 27, 2014 at 7:30 PM, John Wong <gokoproject at gmail.com> wrote:

>
>
> On Thu, Feb 27, 2014 at 6:51 PM, Olemis Lang <olemis at gmail.com> wrote
>
>>
>> The structure is like this
>>
>> + /trunk
>> | +-- bloodhound_dashboard
>> | |    +-- setup.py
>> | |    +-- bhdashboard
>> | |         +-- ... plugin source code with sub packages ...
>> | |         +-- tests
>> | |              +--- ... test code ...
>>
>>
>>> I believe this means tests is also included in the package installation
>>> (when you run setup.py)
>>>
>>
>> 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 .
>>
>>
>
> I know this is not the right place to discuss this, but are you sure? I
> just cloned and did a test.
>
> >>> from bhdashboard.tests import test_report
> In fact, bloodhound_multiproduct is the only package that has tests/ next
> to setup.py. I think all the points you in comment 3 (
> https://issues.apache.org/bloodhound/ticket/770#comment:3) are valid.
>
> To back up your argument:  see
> http://www.ianbicking.org/docs/setuptools-presentation/  slide 20 though.
>
> But sadly, a lot of projects choose to put tests as a subpackage. i
> suspect this surprising outcome has to do with
> http://guide.python-distribute.org/example.html?highlight=test
> For example, Pyramid does it:
> https://github.com/Pylons/pyramid/tree/master/pyramid
> Django webframework users also tend to write tests under each app.
> mysite/user/tests
> mysite/forum/tests
>
> etc.
>
> So why would anyone choose to make tests a subpackage?
> setuptools provides another command called tests (python setup.py tests).
> See
> http://stackoverflow.com/questions/4734292/specifying-where-to-install-tests-require-dependecies-of-a-distribute-setuptoo
> 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's probably the #1 defense.
>
> Ultimately, it'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't know why I
> would ever want to open my interpreter and knowing I could import
> package.tests. That doesn't makes sense. I am not sure if there is a way to
> tell setuptools don't make X directory a subpackage or not. Probably there
> is.
>
> John
>
> _______________________________________________
> testing-in-python mailing list
> testing-in-python at lists.idyll.org
> http://lists.idyll.org/listinfo/testing-in-python
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idyll.org/pipermail/testing-in-python/attachments/20140227/e28a6e63/attachment.htm>