Fixed docs

This commit is contained in:
Tim Chan 2015-11-27 22:46:45 -08:00
parent 604a021a2a
commit a8d7e513f4
8 changed files with 10 additions and 10 deletions

View File

@ -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

View File

@ -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::

View File

@ -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::

View File

@ -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

View File

@ -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.

View File

@ -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

View File

@ -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

View File

@ -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