[TIP] Advice on location of tests modules

[Barry Warsaw]

On Feb 27, 2014, at 04:43 PM, Olemis Lang wrote:

>Recently a discussion has started about the location of test modules
>developed for Apache Bloodhound [1]_ .

Paraphrasing the old joke, if you ask 5 Python programmers you'll get 10
opinions. :)

In my capacity as Debian and Ubuntu developer, I've certainly seen at least
all three of your variations in packages I've looked at.  For my own software,
I strongly prefer:

>  1. Our modified copy of Trac includes multiple test modules
>     i.e. one source code per-package all over across the whole hierarchy

I put a tests subpackage and a docs subpackage right under the subpackage that
they are testing (or documenting <wink>).  I do it this way, especially for
big source trees like Mailman because I want the tests and docs to be as close
to the code as possible.  It makes it *way* easier to find the test for a
specific module.

>I'd rather prefer the option (3) because of the reasons I mentioned in
>bh:comment:3:ticket:770 [2]_ which I repeat below :
>
>  - Having a single top-level tests module (as opposite to Trac's
>    scattered test modules)
>    is convenient considering the package test discovery code

I've gravitated toward nose2 for all my packages, and it has no problem with
layout #1.

>  - For code with functional + unit tests (i.e. quite often) I prefer to
>    write tests in a separate package hierarchy because :
>    * they should not be installed in production deployments

I personally don't care much about that.  I think it doesn't harm anything to
have the tests installed, and might even be useful for debugging.  But I'm not
philosophically opposed to omitting the tests from production code, and in
some of the Debian packaging I've done, we relegate such test directories to a
"-dev" package.

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.idyll.org/pipermail/testing-in-python/attachments/20140227/2799c9a9/attachment.pgp>