[TIP] Guidelines for where to put tests & how to package them

Olemis Lang olemis at gmail.com
Thu Feb 25 06:56:30 PST 2010


On Thu, Feb 25, 2010 at 12:01 AM, C. Titus Brown <ctb at msu.edu> wrote:
> Hi all,
>
> here at PyCon there have been a lot of packaging discussions, so I thought
> I'd spend a bit of time outlining some suggestions for where to put
> tests and how to run them.  It's been a bit of a thorn in the side of
> (among other things) continuous integration systems that there's no
> standard way to run Python tests... so let's fix that!
>

We're gonna save the world . Great !

> I've produced a simple draft proposal & example where you put your unit tests
> under a package dir, somepackage/tests/.
>

I'll take a look in a while ...

> You can run these tests with
>
>  % python -m somepackage.tests.run

-0.5 (... before analyzing your proposal, so you can crucify me ;o)

> and you can also do (if setuptools/distribute is installed)
>
>  % python setup.py test
>

About running the tests, that's the style I'd like to use to run any
test I will write . After Holger's proposal for testrun.org I've been
messing around  a little and I came up with a minimal script [1]_
(after modifying Ronny.Pfannschmidt's [2]_ ;o) that will be smaller
once I configure the real build job (so far I've just been playing and
discovering what's available, what's not, and figuring out why
intermittent jumping little green thingies become yellow without my
explicit permission :P ).

> Comments?

It's great for the start, but I prefer `python setup.py test -m
somepackage.test.run` (not sure about `test.run` yet ...) for testing
everything in there, because it's more explicit, promotes a well known
set of command line arguments and relieson distutils commands (and you
can see by just looking at the command line ;o), so the command can
perform a build or take whatever action it needs in order to satisfy
the preconditions needed to run tests (e.g. installing ). Sometimes
it's also useful to test just a well-known subset of what's been done
(e.g. GViz QL Python client library that's implemented inside TracGviz
plugin ;o) . In that case using -s or similar is useful.

> Thoughts?

/me thinking ... Voilà ! ... tell you in a separate thread to focus on CI
;o)

> Complaints?

How could anybody complain ?

> Issues I missed?

Probably you'll never know ...

:P

.. [1] Build script for `tracgviz_providers` job @ testrun.org
        (http://simelo.pastebin.com/3Znv53v6)

.. [2] [testrun] rfc for python-pseudo-shell-scripts that work on
win32 and linux
        (http://codespeak.net/pipermail/testrun/2010-February/000000.html)

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Further tweaks to the error-handling, in particular: * Paring error,
returning the correct -3...  -
http://bitbucket.org/osimons/trac-rpc-mq/changeset/e9f53ea27bae/



More information about the testing-in-python mailing list