Documentation cleanup - corrected typos & minor stylistic changes.
This commit is contained in:
Jurko Gospodnetić
parent
8307270cec
commit
af0edf0d10
|
|
@ -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
|
||||
list of argvalues for the given argnames. Parametrization is performed
|
||||
""" Add new invocations to the underlying test function using the list
|
||||
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
|
||||
passed as request.param to its respective funcarg factory so that
|
||||
it can perform more expensive setups during the setup phase of
|
||||
:arg indirect: if True each argvalue corresponding to an argument will
|
||||
be passed as request.param to its respective funcarg factory so
|
||||
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
|
||||
so that they are part of the test id. If no ids are provided
|
||||
they will be generated automatically from the argvalues.
|
||||
:arg ids: list of string ids each corresponding to the argvalues so
|
||||
that they are part of the test id. If no ids are provided they will
|
||||
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
|
||||
test function during
|
||||
the collection phase of a test run. Note that request.addcall() is
|
||||
called during the test collection phase prior and independently
|
||||
to actual test execution. You should only use addcall()
|
||||
if you need to specify multiple arguments of a test function
|
||||
""" (deprecated, use parametrize) Add a new call to the underlying
|
||||
test function during the collection phase of a test run. Note that
|
||||
request.addcall() is called during the test collection phase prior and
|
||||
independently to actual test execution. You should only use addcall()
|
||||
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
|
||||
be executed::
|
||||
A third possibility is to use a string to be executed::
|
||||
|
||||
>>> raises(ZeroDivisionError, "f(0)")
|
||||
<ExceptionInfo ...>
|
||||
|
|
|
|||
|
|
@ -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,
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
|
|
|||
|
|
@ -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)
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
with classes to apply markers to all of its test methods::
|
||||
If you are programming with Python 2.6 or later you may use ``pytest.mark``
|
||||
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
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
|
|
|||
|
|
@ -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
|
||||
reporting in ``verbose`` mode::
|
||||
``reportinfo()`` is used for representing the test location and is also
|
||||
consulted when reporting in ``verbose`` mode::
|
||||
|
||||
nonpython $ py.test -v
|
||||
=========================== test session starts ============================
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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 ============================
|
||||
|
|
|
|||
10
doc/faq.txt
10
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
|
||||
a source code and safely find all factory functions for
|
||||
it is nice to be able to search for ``pytest_funcarg__MYARG`` in
|
||||
source code and safely find all factory functions for
|
||||
the ``MYARG`` function argument.
|
||||
|
||||
.. _`Convention over Configuration`: http://en.wikipedia.org/wiki/Convention_over_Configuration
|
||||
|
|
|
|||
|
|
@ -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
|
||||
specific test function call. A request object is passed to a funcarg
|
||||
factory and provides access to test configuration and context:
|
||||
Each funcarg factory receives a **request** object tied to a specific test
|
||||
function call. A request object is passed to a funcarg factory and provides
|
||||
access to test configuration and context:
|
||||
|
||||
.. autoclass:: _pytest.python.FuncargRequest()
|
||||
:members: function,cls,module,keywords,config
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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)
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
at python startup.
|
||||
This file starts coverage collection of subprocesses if appropriate during
|
||||
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.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
of the given module.
|
||||
"""
|
||||
""" setup any state specific to the execution of the given module."""
|
||||
|
||||
def teardown_module(module):
|
||||
""" teardown any state that was previously setup
|
||||
with a setup_module method.
|
||||
""" teardown any state that was previously setup with a setup_module
|
||||
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
|
||||
of the given class (which usually contains tests).
|
||||
""" setup any state specific to the execution of the given class (which
|
||||
usually contains tests).
|
||||
"""
|
||||
|
||||
@classmethod
|
||||
def teardown_class(cls):
|
||||
""" teardown any state that was previously setup
|
||||
with a call to setup_class.
|
||||
""" teardown any state that was previously setup with a call to
|
||||
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
|
||||
method in a class. setup_method is invoked for every
|
||||
test method of a class.
|
||||
""" setup any state tied to the execution of the given method in a
|
||||
class. setup_method is invoked for every test method of a class.
|
||||
"""
|
||||
|
||||
def teardown_method(self, method):
|
||||
""" teardown any state that was previously setup
|
||||
with a setup_method call.
|
||||
""" teardown any state that was previously setup with a setup_method
|
||||
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
|
||||
function. Invoked for every test function in the module.
|
||||
""" setup any state tied to the execution of the given function.
|
||||
Invoked for every test function in the module.
|
||||
"""
|
||||
|
||||
def teardown_function(function):
|
||||
""" teardown any state that was previously setup
|
||||
with a setup_function call.
|
||||
""" teardown any state that was previously setup with a setup_function
|
||||
call.
|
||||
"""
|
||||
|
||||
Note that it possible that setup/teardown pairs are invoked multiple
|
||||
times per testing process.
|
||||
Note that it is possible for setup/teardown pairs to be invoked multiple times
|
||||
per testing process.
|
||||
|
||||
.. _`unittest.py module`: http://docs.python.org/library/unittest.html
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue