Commits

lac  committed ec685c5

minor fixes and one comment

  • Participants
  • Parent commits 75e083b

Comments (0)

Files changed (1)

File doc/goodpractices.txt

 Work with virtual environments
 -----------------------------------------------------------
 
-We recommend to work with virtualenv_ environments and use easy_install_
+We recommend the you 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
+environment. 
+
+XYZZY is 'reprocducible' what you meant to say?  I would have thought 
+      'consistent'.
+
+             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 py.test's primary author.  `tox`_
 is also useful for integration with the continous integration
 server Hudson_.
 
 Use tox and Continous Integration servers
 -------------------------------------------------
 
-If you are (often) releasing code to the public you
+If you frequently release 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 such as your test directory or other
 options.
 
+XYZZY Maybe an example of doing this?
+
 .. _`test discovery`:
 .. _`Python test discovery`:
 
 
 ``py.test`` implements the following standard test discovery:
 
-* collection starts from initial command line arguments
+* collection starts from the 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
+directories.
+
+loking for:
 * ``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
+see :doc:`example/pythoncollection`.
 
 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
+      branches.
 
     * perform ``sys.path.insert(0, basedir)`` to make the fully
       qualified test module path importable.