[TIP] Guidelines for where to put tests & how to package them
Michael Foord
fuzzyman at voidspace.org.uk
Fri Feb 26 10:05:43 PST 2010
On 25/02/2010 05:01, C. Titus Brown 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!
>
> I've produced a simple draft proposal& example where you put your unit tests
> under a package dir, somepackage/tests/.
>
>
I've been using 'somepackage/test/', but 'somepackage/tests/' is fine
with me and it would be better to have one-way-to-do-it.
Note that 'test/' should also be a package (should contain an
__init__.py). I also agree that it is good practise not to have any
dependencies on your test package(s). A top level 'test/' package for
functional / integration tests also sounds fine.
In Python 2.7 / 3.2 you will be able to autodiscover and run unittest
based tests with:
python -m unittest discover
See: http://docs.python.org/dev/library/unittest.html#test-discovery
For Python 2.4-2.6 you can get this functionality (and all the other
nice new functionality in unittest) with the unittest2 package. The way
you use the command line is with the 'unit2' script instead of 'python
-m ...'. See:
http://pypi.python.org/pypi/unittest2
If you *just* want test discovery for unittest, without having to switch
to unittest2, you can use the discover module. Tests are then discovered
with "python -m discover":
http://pypi.python.org/pypi/discover
So lots of options for autodiscovery and running of unittest based tests.
I actually quite like the idea of having a run module in your tests so
that "python -m somepackage.test.run" always works. This allows a single
defined entry point *whichever* test framework you are using. The other
mechanisms discussed depend on the user *knowing* which framework was
used in order to be able to invoke the tests (although if you have
external dependencies they will still need to be installed of course).
All the best,
Michael
> You can run these tests with
>
> % python -m somepackage.tests.run
>
> and you can also do (if setuptools/distribute is installed)
>
> % python setup.py test
>
> ---
>
> Full source at http://github.com/ctb/SomePackage or downloadable
> at
>
> http://lyorn.idyll.org/~t/transfer/SomePackage.tar.gz
>
> Comments? Thoughts? Complaints? Issues I missed?
>
> thanks,
> --titus
>
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
More information about the testing-in-python
mailing list