Work with virtual environments
-We recommend t
o work with virtualenv_ environments and use easy_install_
+We recommend t work with virtualenv_ environments and use easy_install_
(or pip_) for installing your application dependencies as well as
-the ``pytest`` package itself. This way you get a much more reproducible
-environment. A good tool to help you automate test runs against multiple
+the ``pytest`` package itself. This way you will get a much more reproducible
+XYZZY is 'reprocducible' what you meant to say? I would have thought
+ A good tool to help you automate test runs against multiple
dependency configurations or Python interpreters is `tox`_,
-independently created by
the main py.test author. The latter
+independently created by
is also useful for integration with the continous integration
Use tox and Continous Integration servers
are (often) releas ing code to the public you
+If you re releas code to the public you
may want to look into `tox`_, the virtualenv test automation
tool and its `pytest support <http://codespeak.net/tox/example/pytest.html>`_.
The basic idea is to generate a JUnitXML file through the ``--junitxml=PATH`` option and have a continous integration server like Hudson_ pick it up.
this will execute your tests using ``runtest.py``. As this is a
standalone version of ``py.test`` no prior installation whatsoever is
required for calling the test command. You can also pass additional
-arguments to the subprocess-calls
like your test directory or other
+arguments to the subprocess-calls your test directory or other
+XYZZY Maybe an example of doing this?
.. _`Python test discovery`:
``py.test`` implements the following standard test discovery:
-* collection starts from initial command line arguments
+* collection starts from initial command line arguments
which may be directories, filenames or test ids.
-* recurse into directories, unless they match :confval:`norecursedirs`
+* It then recurses into directories, unless they match :confval:`norecursedirs`
+XYZZY Again, I am not sure this isn't incorrect English, albeit commonly
+used incorrect English, and you should be talkiing about descending into
* ``test_*.py`` or ``*_test.py`` files, imported by their `package name`_.
* ``Test`` prefixed test classes (without an ``__init__`` method)
* ``test_`` prefixed test functions or methods are test items
-For changing and customization example, see :doc:`example/pythoncollection`.
+For and example of how to modify and customize your test discovery
py.test additionally discovers tests using the standard
:ref:`unittest.TestCase <unittest.TestCase>` subclassing technique.
Test modules are imported under their fully qualified name as follows:
- * find ``basedir`` -- this is the first "upward" directory not
- containing an ``__init__.py``
+ * find ``basedir`` -- this is the first "upward" (towards the root)
+ directory not containing an ``__init__.py``
+XYZZY it's odd that in csc, up in a tree is towards its root, not its
* perform ``sys.path.insert(0, basedir)`` to make the fully
qualified test module path importable.