Documentation cleanup - corrected typos & minor stylistic changes.

_pytest/python.py

@@ -588,8 +588,8 @@ class Metafunc:
         self._ids = py.builtin.set()
 
     def parametrize(self, argnames, argvalues, indirect=False, ids=None):
-        """ add new invocations to the underlying test function using the
+        """ Add new invocations to the underlying test function using the list
-        list of argvalues for the given argnames.  Parametrization is performed
+        of argvalues for the given argnames.  Parametrization is performed
         during the collection phase.  If you need to setup expensive resources
         you may pass indirect=True and implement a funcarg factory which can
         perform the expensive setup just before a test is actually run.
@@ -599,14 +599,14 @@ class Metafunc:
         :arg argvalues: a list of values for the argname or a list of tuples of
             values for the list of argument names.
 
-        :arg indirect: if True each argvalue corresponding to an argument will be
+        :arg indirect: if True each argvalue corresponding to an argument will
-            passed as request.param to its respective funcarg factory so that
+            be passed as request.param to its respective funcarg factory so
-            it can perform more expensive setups during the setup phase of
+            that it can perform more expensive setups during the setup phase of
             a test rather than at collection time.
 
-        :arg ids: list of string ids each corresponding to the argvalues
+        :arg ids: list of string ids each corresponding to the argvalues so
-            so that they are part of the test id. If no ids are provided
+            that they are part of the test id. If no ids are provided they will
-            they will be generated automatically from the argvalues.
+            be generated automatically from the argvalues.
         """
         if not isinstance(argnames, (tuple, list)):
             argnames = (argnames,)
@@ -628,12 +628,11 @@ class Metafunc:
         self._calls = newcalls
 
     def addcall(self, funcargs=None, id=_notexists, param=_notexists):
-        """ (deprecated, use parametrize) add a new call to the underlying
+        """ (deprecated, use parametrize) Add a new call to the underlying
-        test function during
+        test function during the collection phase of a test run.  Note that
-        the collection phase of a test run.  Note that request.addcall() is
+        request.addcall() is called during the test collection phase prior and
-        called during the test collection phase prior and independently
+        independently to actual test execution.  You should only use addcall()
-        to actual test execution.  You should only use addcall()
+        if you need to specify multiple arguments of a test function.
-        if you need to specify multiple arguments of a test function
 
         :arg funcargs: argument keyword dictionary used when invoking
             the test function.
@@ -750,7 +749,7 @@ class FuncargRequest:
 
 
     def applymarker(self, marker):
-        """ apply a marker to a single test function invocation.
+        """ Apply a marker to a single test function invocation.
         This method is useful if you don't want to have a keyword/marker
         on all function invocations.
 
@@ -762,7 +761,7 @@ class FuncargRequest:
         self._pyfuncitem.keywords[marker.markname] = marker
 
     def cached_setup(self, setup, teardown=None, scope="module", extrakey=None):
-        """ return a testing resource managed by ``setup`` &
+        """ Return a testing resource managed by ``setup`` &
         ``teardown`` calls.  ``scope`` and ``extrakey`` determine when the
         ``teardown`` function will be called so that subsequent calls to
         ``setup`` would recreate the resource.
@@ -937,8 +936,7 @@ def raises(ExpectedException, *args, **kwargs):
         >>> raises(ZeroDivisionError, f, x=0)
         <ExceptionInfo ...>
 
-    A third possibility is to use a string which which will
+    A third possibility is to use a string to be executed::
-    be executed::
 
         >>> raises(ZeroDivisionError, "f(0)")
         <ExceptionInfo ...>

doc/announce/release-2.0.2.txt

@@ -1,4 +1,4 @@
-py.test 2.0.2: bug fixes, improved xfail/skip expressions, speedups
+py.test 2.0.2: bug fixes, improved xfail/skip expressions, speed ups
 ===========================================================================
 
 Welcome to pytest-2.0.2, a maintenance and bug fix release of pytest,

doc/announce/release-2.1.0.txt

@@ -1,7 +1,7 @@
 py.test 2.1.0: perfected assertions and bug fixes
 ===========================================================================
 
-Welcome to the relase of pytest-2.1, a mature testing tool for Python,
+Welcome to the release of pytest-2.1, a mature testing tool for Python,
 supporting CPython 2.4-3.2, Jython and latest PyPy interpreters.  See
 the improved extensive docs (now also as PDF!) with tested examples here:
 
@@ -39,10 +39,9 @@ Changes between 2.0.3 and 2.1.0
   unexpected exceptions
 - fix issue47: timing output in junitxml for test cases is now correct
 - fix issue48: typo in MarkInfo repr leading to exception
-- fix issue49: avoid confusing error when initizaliation partially fails
+- fix issue49: avoid confusing error when initialization partially fails
 - fix issue44: env/username expansion for junitxml file path
 - show releaselevel information in test runs for pypy
 - reworked doc pages for better navigation and PDF generation
 - report KeyboardInterrupt even if interrupted during session startup
 - fix issue 35 - provide PDF doc version and download link from index page
-

doc/announce/release-2.2.0.txt

@@ -69,19 +69,19 @@ Changes between 2.1.3 and 2.2.0
   teardown function are called earlier.
 - add an all-powerful metafunc.parametrize function which allows to
   parametrize test function arguments in multiple steps and therefore
-  from indepdenent plugins and palces. 
+  from independent plugins and places.
 - add a @pytest.mark.parametrize helper which allows to easily
-  call a test function with different argument values
+  call a test function with different argument values.
 - Add examples to the "parametrize" example page, including a quick port
   of Test scenarios and the new parametrize function and decorator.
 - introduce registration for "pytest.mark.*" helpers via ini-files
   or through plugin hooks.  Also introduce a "--strict" option which
   will treat unregistered markers as errors
   allowing to avoid typos and maintain a well described set of markers
-  for your test suite.  See exaples at http://pytest.org/latest/mark.html
+  for your test suite.  See examples at http://pytest.org/latest/mark.html
   and its links.
 - issue50: introduce "-m marker" option to select tests based on markers
-  (this is a stricter and more predictable version of '-k' in that "-m"
+  (this is a stricter and more predictable version of "-k" in that "-m"
   only matches complete markers and has more obvious rules for and/or
   semantics.
 - new feature to help optimizing the speed of your tests:

doc/assert.txt

@@ -73,7 +73,7 @@ and if you need to have access to the actual exception info you may use::
 
     # do checks related to excinfo.type, excinfo.value, excinfo.traceback
 
-If you want to write test code that works on Python2.4 as well,
+If you want to write test code that works on Python 2.4 as well,
 you may also use two other ways to test for an expected exception::
 
     pytest.raises(ExpectedException, func, *args, **kwargs)

doc/customize.txt

@@ -64,13 +64,13 @@ Builtin configuration file options
 
 .. confval:: minversion
 
-   specifies a minimal pytest version required for running tests.
+   Specifies a minimal pytest version required for running tests.
 
         minversion = 2.1  # will fail if we run with pytest-2.0
 
 .. confval:: addopts
 
-   add the specified ``OPTS`` to the set of command line arguments as if they
+   Add the specified ``OPTS`` to the set of command line arguments as if they
    had been specified by the user. Example: if you have this ini file content::
 
        [pytest]
@@ -121,4 +121,3 @@ Builtin configuration file options
    and methods are considered as test modules.
 
    See :ref:`change naming conventions` for examples.
-

doc/example/index.txt

@@ -9,7 +9,7 @@ need more examples or have questions. Also take a look at the :ref:`comprehensiv
 
 .. note::
 
-   see :doc:`../getting-started` for basic introductionary examples
+   see :doc:`../getting-started` for basic introductory examples
 
 .. toctree::
    :maxdepth: 2

doc/example/markers.txt

@@ -6,7 +6,7 @@ Working with custom markers
 
 Here are some example using the :ref:`mark` mechanism.
 
-marking test functions and selecting them for a run
+Marking test functions and selecting them for a run
 ----------------------------------------------------
 
 You can "mark" a test function with custom metadata like this::
@@ -96,8 +96,8 @@ For an example on how to add and work with markers from a plugin, see
 Marking whole classes or modules
 ----------------------------------------------------
 
-If you are programming with Python2.6 you may use ``pytest.mark`` decorators
+If you are programming with Python 2.6 or later you may use ``pytest.mark``
-with classes to apply markers to all of its test methods::
+decorators with classes to apply markers to all of its test methods::
 
     # content of test_mark_classlevel.py
     import pytest
@@ -111,7 +111,7 @@ with classes to apply markers to all of its test methods::
 This is equivalent to directly applying the decorator to the
 two test functions.
 
-To remain backward-compatible with Python2.4 you can also set a
+To remain backward-compatible with Python 2.4 you can also set a
 ``pytestmark`` attribute on a TestClass like this::
 
     import pytest
@@ -137,7 +137,8 @@ methods defined in the module.
 Using ``-k TEXT`` to select tests
 ----------------------------------------------------
 
-You can use the ``-k`` command line option to only run tests with names that match the given argument::
+You can use the ``-k`` command line option to only run tests with names matching
+the given argument::
 
     $ py.test -k send_http  # running with the above defined examples
     ============================= test session starts ==============================
@@ -176,7 +177,7 @@ Or to only select the class::
 
 .. _`adding a custom marker from a plugin`:
 
-custom marker and command line option to control test runs
+Custom marker and command line option to control test runs
 ----------------------------------------------------------
 
 .. regendoc:wipe

doc/example/mysetup.txt

@@ -38,7 +38,7 @@ method in a :ref:`local plugin <localplugin>` ::
         def myapp(self):
             return MyApp()
 
-To run the example we stub out a a simple ``MyApp`` application object::
+To run the example we stub out a simple ``MyApp`` application object::
 
     # content of myapp.py
     class MyApp:

doc/example/nonpython.txt

@@ -51,8 +51,8 @@ your own domain specific testing language this way.
     representation string of your choice.  It
     will be reported as a (red) string.
 
-``reportinfo()`` is used for representing the test location and is also consulted for
+``reportinfo()`` is used for representing the test location and is also
-reporting in ``verbose`` mode::
+consulted when reporting in ``verbose`` mode::
 
     nonpython $ py.test -v
     =========================== test session starts ============================

doc/example/parametrize.txt

@@ -12,7 +12,7 @@ the builtin mechanisms.
 
 .. _parametrizemark:
 
-simple "decorator" parametrization of a test function
+Simple "decorator" parametrization of a test function
 ----------------------------------------------------------------------------
 
 .. versionadded:: 2.2
@@ -119,12 +119,12 @@ let's run the full monty::
 As expected when running the full range of ``param1`` values
 we'll get an error on the last one.
 
-a quick port of "testscenarios"
+A quick port of "testscenarios"
 ------------------------------------
 
 .. _`test scenarios`: http://bazaar.launchpad.net/~lifeless/testscenarios/trunk/annotate/head%3A/doc/example.py
 
-Here is a quick port of to run tests configured with `test scenarios`_,
+Here is a quick port to run tests configured with `test scenarios`_,
 an add-on from Robert Collins for the standard unittest framework. We
 only have to work a bit to construct the correct arguments for pytest's
 :py:func:`Metafunc.parametrize`::
@@ -260,7 +260,7 @@ Parametrizing test methods through per-class configuration
 
 
 Here is an example ``pytest_generate_function`` function implementing a
-parametrization scheme similar to Michael Foords `unittest
+parametrization scheme similar to Michael Foord's `unittest
 parameterizer`_ but in a lot less code::
 
     # content of ./test_parametrize.py

doc/example/simple.txt

@@ -242,7 +242,7 @@ and then check for the ``sys._called_from_test`` flag::
         # called "normally"
 
 accordingly in your application.  It's also a good idea
-to rather use your own application module rather than ``sys``
+to use your own application module rather than ``sys``
 for handling flag.
 
 Adding info to test report header
@@ -308,7 +308,7 @@ profiling test duration
 .. versionadded: 2.2
 
 If you have a slow running large test suite you might want to find
-out which tests are slowest. Let's make an artifical test suite::
+out which tests are the slowest. Let's make an artifical test suite::
 
     # content of test_some_are_slow.py
 
@@ -323,7 +323,7 @@ out which tests are slowest. Let's make an artifical test suite::
     def test_funcslow2():
         time.sleep(0.2)
 
-Now we can profile which test functions execute slowest::
+Now we can profile which test functions execute the slowest::
 
     $ py.test --durations=3
     =========================== test session starts ============================

doc/faq.txt

@@ -18,7 +18,7 @@ utilities, all starting with ``py.<TAB>``, thus providing nice
 TAB-completion. If
 you install ``pip install pycmd`` you get these tools from a separate
 package.  These days the command line tool could be called ``pytest``
-since many people have gotten used to the old name and there
+but since many people have gotten used to the old name and there
 is another tool named "pytest" we just decided to stick with
 ``py.test``.
 
@@ -47,13 +47,13 @@ customizable testing frameworks for Python.   However,
 ``py.test`` still uses many metaprogramming techniques and
 reading its source is thus likely not something for Python beginners.
 
-A second "magic" issue arguably the assert statement debugging feature. When
+A second "magic" issue is arguably the assert statement debugging feature. When
 loading test modules py.test rewrites the source code of assert statements. When
 a rewritten assert statement fails, its error message has more information than
 the original. py.test also has a second assert debugging technique. When an
 ``assert`` statement that was missed by the rewriter fails, py.test
 re-interprets the expression to show intermediate values if a test fails. This
-second technique suffers from caveat that the rewriting does not: If your
+second technique suffers from a caveat that the rewriting does not: If your
 expression has side effects (better to avoid them anyway!) the intermediate
 values may not be the same, confusing the reinterpreter and obfuscating the
 initial error (this is also explained at the command line if it happens).
@@ -91,8 +91,8 @@ Why the ``pytest_funcarg__*`` name for funcarg factories?
 
 We like `Convention over Configuration`_ and didn't see much point
 in allowing a more flexible or abstract mechanism.  Moreover,
-is is nice to be able to search for ``pytest_funcarg__MYARG`` in
+it is nice to be able to search for ``pytest_funcarg__MYARG`` in
-a source code and safely find all factory functions for
+source code and safely find all factory functions for
 the ``MYARG`` function argument.
 
 .. _`Convention over Configuration`: http://en.wikipedia.org/wiki/Convention_over_Configuration

doc/funcargs.txt

@@ -16,7 +16,7 @@ control their life cycle in relation to the test execution. It is
 also possible to run a test function multiple times with different objects.
 
 The basic mechanism for injecting objects is also called the
-*funcarg mechanism* because objects are ultimatly injected
+*funcarg mechanism* because objects are ultimately injected
 by calling a test function with it as an argument.  Unlike the
 classical xUnit approach *funcargs* relate more to `Dependency Injection`_
 because they help to de-couple test code from objects required for
@@ -119,9 +119,9 @@ think of as "resources").
 The funcarg **request** object
 =============================================
 
-Each funcarg factory receives a **request** object which is tied to a
+Each funcarg factory receives a **request** object tied to a specific test
-specific test function call.  A request object is passed to a funcarg
+function call.  A request object is passed to a funcarg factory and provides
-factory and provides access to test configuration and context:
+access to test configuration and context:
 
 .. autoclass:: _pytest.python.FuncargRequest()
     :members: function,cls,module,keywords,config

doc/goodpractises.txt

@@ -21,7 +21,7 @@ dependency configurations or Python interpreters is `tox`_.
 Use tox and Continuous Integration servers
 -------------------------------------------------
 
-If you frequently relase 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 continuous integration server like Jenkins_ pick it up
@@ -30,7 +30,7 @@ and generate reports.
 .. _standalone:
 .. _`genscript method`:
 
-Create a py.test standalone Script
+Create a py.test standalone script
 -------------------------------------------
 
 If you are a maintainer or application developer and want others

doc/plugins.txt

@@ -264,7 +264,7 @@ specification.  However, a hook function may accept *fewer* parameters
 by simply not specifying them.  If you mistype argument names or the
 hook name itself you get an error showing the available arguments.
 
-Initialisation, command line and configuration hooks
+Initialization, command line and configuration hooks
 --------------------------------------------------------------------
 
 .. currentmodule:: _pytest.hookspec

doc/recwarn.txt

@@ -1,5 +1,5 @@
 
-Asserting deprecation and other warnings.
+Asserting deprecation and other warnings
 =====================================================
 
 The recwarn function argument
@@ -35,4 +35,3 @@ warning::
 
     def test_global():
         pytest.deprecated_call(myfunction, 17)
-

doc/test/plugin/cov.txt

@@ -35,10 +35,11 @@ However easy_install does not provide an uninstall facility.
 
 .. IMPORTANT::
 
-    Ensure that you manually delete the init_covmain.pth file in your site-packages directory.
+    Ensure that you manually delete the init_covmain.pth file in your
+    site-packages directory.
 
-    This file starts coverage collection of subprocesses if appropriate during site initialisation
+    This file starts coverage collection of subprocesses if appropriate during
-    at python startup.
+    site initialization at python startup.
 
 
 Usage
@@ -198,7 +199,7 @@ slave.
 
 For subprocess measurement environment variables must make it from the main process to the
 subprocess.  The python used by the subprocess must have pytest-cov installed.  The subprocess must
-do normal site initialisation so that the environment variables can be detected and coverage
+do normal site initialization so that the environment variables can be detected and coverage
 started.
 
 

doc/usage.txt

@@ -96,7 +96,7 @@ can use a helper::
 .. versionadded: 2.0.0
 
 In previous versions you could only enter PDB tracing if
-you disable capturing on the command line via ``py.test -s``.
+you disabled capturing on the command line via ``py.test -s``.
 
 .. _durations:
 

doc/xunit_setup.txt

@@ -24,13 +24,11 @@ module you can optionally implement the following fixture methods
 which will usually be called once for all the functions::
 
     def setup_module(module):
-        """ setup up any state specific to the execution
+        """ setup any state specific to the execution of the given module."""
-            of the given module.
-        """
 
     def teardown_module(module):
-        """ teardown any state that was previously setup
+        """ teardown any state that was previously setup with a setup_module
-            with a setup_module method.
+        method.
         """
 
 Class level setup/teardown
@@ -41,14 +39,14 @@ and after all test methods of the class are called::
 
     @classmethod
     def setup_class(cls):
-        """ setup up any state specific to the execution
+        """ setup any state specific to the execution of the given class (which
-            of the given class (which usually contains tests).
+        usually contains tests).
         """
 
     @classmethod
     def teardown_class(cls):
-        """ teardown any state that was previously setup
+        """ teardown any state that was previously setup with a call to
-            with a call to setup_class.
+        setup_class.
         """
 
 Method and function level setup/teardown
@@ -57,31 +55,29 @@ Method and function level setup/teardown
 Similarly, the following methods are called around each method invocation::
 
     def setup_method(self, method):
-        """ setup up any state tied to the execution of the given
+        """ setup any state tied to the execution of the given method in a
-        method in a class.  setup_method is invoked for every
+        class.  setup_method is invoked for every test method of a class.
-        test method of a class.
         """
 
     def teardown_method(self, method):
-        """ teardown any state that was previously setup
+        """ teardown any state that was previously setup with a setup_method
-        with a setup_method call.
+        call.
         """
 
 If you would rather define test functions directly at module level
 you can also use the following functions to implement fixtures::
 
     def setup_function(function):
-        """ setup up any state tied to the execution of the given
+        """ setup any state tied to the execution of the given function.
-        function. Invoked for every test function in the module.
+        Invoked for every test function in the module.
         """
 
     def teardown_function(function):
-        """ teardown any state that was previously setup
+        """ teardown any state that was previously setup with a setup_function
-        with a setup_function call.
+        call.
         """
 
-Note that it possible that setup/teardown pairs are invoked multiple
+Note that it is possible for setup/teardown pairs to be invoked multiple times
-times per testing process.
+per testing process.
 
 .. _`unittest.py module`: http://docs.python.org/library/unittest.html
-