diff --git a/doc/en/example/parametrize.rst b/doc/en/example/parametrize.rst index ca8f0aec1..1447c7253 100644 --- a/doc/en/example/parametrize.rst +++ b/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 diff --git a/doc/en/example/pythoncollection.rst b/doc/en/example/pythoncollection.rst index 80a997368..e71285adc 100644 --- a/doc/en/example/pythoncollection.rst +++ b/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:: diff --git a/doc/en/example/simple.rst b/doc/en/example/simple.rst index bd295e9c0..b7a2caee6 100644 --- a/doc/en/example/simple.rst +++ b/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 ` 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:: diff --git a/doc/en/faq.rst b/doc/en/faq.rst index c6de844ec..f91c953f9 100644 --- a/doc/en/faq.rst +++ b/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 `. This completely avoids previous issues of confusing assertion-reporting. It also means, that you can use Python's ``-O`` optimization without losing diff --git a/doc/en/funcarg_compare.rst b/doc/en/funcarg_compare.rst index 4d2331787..832922e18 100644 --- a/doc/en/funcarg_compare.rst +++ b/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. diff --git a/doc/en/unittest.rst b/doc/en/unittest.rst index 198ebe841..28a4c9321 100644 --- a/doc/en/unittest.rst +++ b/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 diff --git a/doc/en/usage.rst b/doc/en/usage.rst index 0ac698ff8..2deaadb5d 100644 --- a/doc/en/usage.rst +++ b/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 diff --git a/doc/en/writing_plugins.rst b/doc/en/writing_plugins.rst index 4be2516f4..0baa9c16d 100644 --- a/doc/en/writing_plugins.rst +++ b/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