Merge pull request #1200 from macrotim/master

Merge #1200 - correct various documentation spelling misstakes

doc/en/example/parametrize.rst

@@ -333,12 +333,12 @@ The result of this test will be successful::
 Parametrizing test methods through per-class configuration
 --------------------------------------------------------------
 
-.. _`unittest parameterizer`: http://code.google.com/p/unittest-ext/source/browse/trunk/params.py
+.. _`unittest parametrizer`: http://code.google.com/p/unittest-ext/source/browse/trunk/params.py
 
 
 Here is an example ``pytest_generate_function`` function implementing a
 parametrization scheme similar to Michael Foord's `unittest
-parameterizer`_ but in a lot less code::
+parametrizer`_ but in a lot less code::
 
     # content of ./test_parametrize.py
     import pytest

doc/en/example/pythoncollection.rst

@@ -175,7 +175,7 @@ And then if you have a module file like this::
 and a setup.py dummy file like this::
 
     # content of setup.py
-    0/0  # will raise exeption if imported
+    0/0  # will raise exception if imported
 
 then a pytest run on python2 will find the one test when run with a python2
 interpreters and will leave out the setup.py file::

doc/en/example/simple.rst

@@ -313,7 +313,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 the slowest. Let's make an artifical test suite::
+out which tests are the slowest. Let's make an artificial test suite::
 
     # content of test_some_are_slow.py
 
@@ -427,7 +427,7 @@ by placing fixture functions in a ``conftest.py`` file in that directory
 You can use all types of fixtures including :ref:`autouse fixtures
 <autouse fixtures>` which are the equivalent of xUnit's setup/teardown
 concept.  It's however recommended to have explicit fixture references in your
-tests or test classes rather than relying on implicitely executing
+tests or test classes rather than relying on implicitly executing
 setup/teardown functions, especially if they are far away from the actual tests.
 
 Here is a an example for making a ``db`` fixture available in a directory::

doc/en/faq.rst

@@ -60,7 +60,7 @@ and customizable testing framework for Python.   Note, however, that
 thus likely not something for Python beginners.
 
 A second "magic" issue was the assert statement debugging feature.
-Nowadays, ``pytest`` explicitely rewrites assert statements in test modules
+Nowadays, ``pytest`` explicitly rewrites assert statements in test modules
 in order to provide more useful :ref:`assert feedback <assertfeedback>`.
 This completely avoids previous issues of confusing assertion-reporting.
 It also means, that you can use Python's ``-O`` optimization without losing

doc/en/funcarg_compare.rst

@@ -209,7 +209,7 @@ fixtures:
   and let pytest figure things out for you.
 
 * if you used parametrization and funcarg factories which made use of
-  ``request.cached_setup()`` it is recommeneded to invest a few minutes
+  ``request.cached_setup()`` it is recommended to invest a few minutes
   and simplify your fixture function code to use the :ref:`@pytest.fixture`
   decorator instead.  This will also allow to take advantage of 
   the automatic per-resource grouping of tests.

doc/en/unittest.rst

@@ -126,7 +126,7 @@ when writing the class-scoped fixture function above.
 autouse fixtures and accessing other fixtures
 -------------------------------------------------------------------
 
-Although it's usually better to explicitely declare use of fixtures you need
+Although it's usually better to explicitly declare use of fixtures you need
 for a given test, you may sometimes want to have fixtures that are 
 automatically used in a given context.  After all, the traditional 
 style of unittest-setup mandates the use of this implicit fixture writing

doc/en/usage.rst

@@ -123,7 +123,7 @@ automatically disables its output capture when you enter PDB_ tracing:
   such.
 * Any later output produced within the same test will not be captured and will
   instead get sent directly to ``sys.stdout``. Note that this holds true even
-  for test output occuring after you exit the interactive PDB_ tracing session
+  for test output occurring after you exit the interactive PDB_ tracing session
   and continue with the regular test run.
 
 .. versionadded: 2.4.0

doc/en/writing_plugins.rst

@@ -204,7 +204,7 @@ plugin.  Given that you have an installed plugin you can enable the
 :py:class:`testdir <_pytest.pytester.Testdir>` fixture via specifying a
 command line option to include the pytester plugin (``-p pytester``) or
 by putting ``pytest_plugins = "pytester"`` into your test or
-``conftest.py`` file.  You then will have a ``testdir`` fixure which you
+``conftest.py`` file.  You then will have a ``testdir`` fixture which you
 can use like this::
 
     # content of test_myplugin.py