Capitalised start of headlines, added -ing to a few headlines.
This commit is contained in:
Dinu Gherman
parent
8675cf640d
commit
fab7615c8a
|
|
@ -4,7 +4,7 @@ The writing and reporting of assertions in tests
|
|||
|
||||
.. _`assert with the assert statement`:
|
||||
|
||||
assert with the ``assert`` statement
|
||||
Asserting with the ``assert`` statement
|
||||
---------------------------------------------------------
|
||||
|
||||
``py.test`` allows you to use the standard python ``assert`` for verifying
|
||||
|
|
@ -54,7 +54,7 @@ will be simply shown in the traceback.
|
|||
|
||||
See :ref:`assert-details` for more information on assertion introspection.
|
||||
|
||||
assertions about expected exceptions
|
||||
Assertions about expected exceptions
|
||||
------------------------------------------
|
||||
|
||||
In order to write assertions about raised exceptions, you can use
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
|
||||
.. _`pytest helpers`:
|
||||
|
||||
pytest builtin helpers
|
||||
Pytest builtin helpers
|
||||
================================================
|
||||
|
||||
builtin pytest.* functions and helping objects
|
||||
|
|
@ -17,7 +17,7 @@ to get an overview on the globally available helpers.
|
|||
.. automodule:: pytest
|
||||
:members:
|
||||
|
||||
builtin function arguments
|
||||
Builtin function arguments
|
||||
-----------------------------------------------------
|
||||
|
||||
You can ask for available builtin or project-custom
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
basic test configuration
|
||||
Basic test configuration
|
||||
===================================
|
||||
|
||||
Command line options and configuration file settings
|
||||
|
|
@ -59,7 +59,7 @@ progress output, you can write it into a configuration file::
|
|||
|
||||
From now on, running ``py.test`` will add the specified options.
|
||||
|
||||
builtin configuration file options
|
||||
Builtin configuration file options
|
||||
----------------------------------------------
|
||||
|
||||
.. confval:: minversion
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
|
||||
doctest integration for modules and test files
|
||||
Doctest integration for modules and test files
|
||||
=========================================================
|
||||
|
||||
By default all files matching the ``test*.txt`` pattern will
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
|
||||
.. _mysetup:
|
||||
|
||||
mysetup pattern: application specific test fixtures
|
||||
Mysetup pattern: application specific test fixtures
|
||||
==========================================================
|
||||
|
||||
Here is a basic useful step-by-step example for managing and interacting
|
||||
|
|
@ -12,8 +12,8 @@ where we have the glue and test support code for bootstrapping and
|
|||
configuring application objects and allow test modules and test
|
||||
functions to stay ignorant of involved details.
|
||||
|
||||
step1: implementing the test/app-specific ``mysetup`` pattern
|
||||
-------------------------------------------------------------
|
||||
Step 1: Implementing the test/app-specific ``mysetup`` pattern
|
||||
--------------------------------------------------------------
|
||||
|
||||
Let's write a simple test function using a ``mysetup`` funcarg::
|
||||
|
||||
|
|
@ -76,7 +76,7 @@ the concrete question or answers actually mean, please see here_.
|
|||
.. _here: http://uncyclopedia.wikia.com/wiki/The_Hitchhiker's_Guide_to_the_Galaxy
|
||||
.. _`tut-cmdlineoption`:
|
||||
|
||||
step 2: checking a command line option and skipping tests
|
||||
Step 2: Checking a command line option and skipping tests
|
||||
-----------------------------------------------------------
|
||||
|
||||
To add a command line option we update the ``conftest.py`` of
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ Working with non-python tests
|
|||
|
||||
.. _`yaml plugin`:
|
||||
|
||||
a basic example for specifying tests in Yaml files
|
||||
A basic example for specifying tests in Yaml files
|
||||
--------------------------------------------------------------
|
||||
|
||||
.. _`pytest-yamlwsgi`: http://bitbucket.org/aafshar/pytest-yamlwsgi/src/tip/pytest_yamlwsgi.py
|
||||
|
|
|
|||
|
|
@ -1,14 +1,14 @@
|
|||
|
||||
.. _paramexamples:
|
||||
|
||||
parametrizing tests
|
||||
Parametrizing tests
|
||||
=================================================
|
||||
|
||||
py.test allows to easily implement your own custom
|
||||
parametrization scheme for tests. Here we provide
|
||||
some examples for inspiration and re-use.
|
||||
|
||||
generating parameters combinations, depending on command line
|
||||
Generating parameters combinations, depending on command line
|
||||
----------------------------------------------------------------------------
|
||||
|
||||
.. regendoc:wipe
|
||||
|
|
@ -272,7 +272,7 @@ Running it gives similar results as before::
|
|||
test_parametrize2.py:23: Failed
|
||||
2 failed, 2 passed in 0.02 seconds
|
||||
|
||||
checking serialization between Python interpreters
|
||||
Checking serialization between Python interpreters
|
||||
--------------------------------------------------------------
|
||||
|
||||
Here is a stripped down real-life example of using parametrized
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
Changing standard (Python) test discovery
|
||||
===============================================
|
||||
|
||||
changing directory recursion
|
||||
Changing directory recursion
|
||||
-----------------------------------------------------
|
||||
|
||||
You can set the :confval:`norecursedirs` option in an ini-file, for example your ``setup.cfg`` in the project root directory::
|
||||
|
|
@ -14,7 +14,7 @@ This would tell py.test to not recurse into typical subversion or sphinx-build d
|
|||
|
||||
.. _`change naming conventions`:
|
||||
|
||||
change naming conventions
|
||||
Changing naming conventions
|
||||
-----------------------------------------------------
|
||||
|
||||
You can configure different naming conventions by setting
|
||||
|
|
@ -53,7 +53,7 @@ then the test collection looks like this::
|
|||
|
||||
============================= in 0.01 seconds =============================
|
||||
|
||||
interpret cmdline arguments as Python packages
|
||||
Interpreting cmdline arguments as Python packages
|
||||
-----------------------------------------------------
|
||||
|
||||
You can use the ``--pyargs`` option to make py.test try
|
||||
|
|
@ -75,7 +75,7 @@ Now a simple invocation of ``py.test NAME`` will check
|
|||
if NAME exists as an importable package/module and otherwise
|
||||
treat it as a filesystem path.
|
||||
|
||||
finding out what is collected
|
||||
Finding out what is collected
|
||||
-----------------------------------------------
|
||||
|
||||
You can always peek at the collection tree without running tests like this::
|
||||
|
|
|
|||
|
|
@ -1,10 +1,10 @@
|
|||
|
||||
.. highlightlang:: python
|
||||
|
||||
basic patterns and examples
|
||||
Basic patterns and examples
|
||||
==========================================================
|
||||
|
||||
pass different values to a test function, depending on command line options
|
||||
Pass different values to a test function, depending on command line options
|
||||
----------------------------------------------------------------------------
|
||||
|
||||
.. regendoc:wipe
|
||||
|
|
@ -85,7 +85,7 @@ next example or refer to :ref:`mysetup` for more information
|
|||
on real-life examples.
|
||||
|
||||
|
||||
dynamically adding command line options
|
||||
Dynamically adding command line options
|
||||
--------------------------------------------------------------
|
||||
|
||||
.. regendoc:wipe
|
||||
|
|
@ -119,7 +119,7 @@ directory with the above conftest.py::
|
|||
|
||||
.. _`excontrolskip`:
|
||||
|
||||
control skipping of tests according to command line option
|
||||
Control skipping of tests according to command line option
|
||||
--------------------------------------------------------------
|
||||
|
||||
.. regendoc:wipe
|
||||
|
|
@ -176,7 +176,7 @@ Or run it including the ``slow`` marked test::
|
|||
|
||||
========================= 2 passed in 0.01 seconds =========================
|
||||
|
||||
writing well integrated assertion helpers
|
||||
Writing well integrated assertion helpers
|
||||
--------------------------------------------------
|
||||
|
||||
.. regendoc:wipe
|
||||
|
|
|
|||
|
|
@ -63,7 +63,7 @@ You can turn off all assertion debugging with ``py.test --assertmode=off``.
|
|||
.. _`py/__init__.py`: http://bitbucket.org/hpk42/py-trunk/src/trunk/py/__init__.py
|
||||
|
||||
|
||||
function arguments, parametrized tests and setup
|
||||
Function arguments, parametrized tests and setup
|
||||
-------------------------------------------------------
|
||||
|
||||
.. _funcargs: test/funcargs.html
|
||||
|
|
|
|||
|
|
@ -182,7 +182,7 @@ You can find out what kind of builtin :ref:`funcargs` exist by typing::
|
|||
|
||||
py.test --funcargs # shows builtin and custom function arguments
|
||||
|
||||
where to go next
|
||||
Where to go next
|
||||
-------------------------------------
|
||||
|
||||
Here are a few suggestions where to go next:
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
|
||||
.. _mark:
|
||||
|
||||
mark test functions with attributes
|
||||
Marking test functions with attributes
|
||||
=================================================================
|
||||
|
||||
.. currentmodule:: _pytest.mark
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
|
||||
monkeypatching/mocking modules and environments
|
||||
Monkeypatching/mocking modules and environments
|
||||
================================================================
|
||||
|
||||
.. currentmodule:: _pytest.monkeypatch
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
Running test written for nose
|
||||
Running tests written for nose
|
||||
=======================================
|
||||
|
||||
.. include:: links.inc
|
||||
|
|
|
|||
|
|
@ -203,7 +203,7 @@ and their names. It will also print local plugins aka
|
|||
|
||||
.. _`cmdunregister`:
|
||||
|
||||
deactivate / unregister a plugin by name
|
||||
Deactivating / unregistering a plugin by name
|
||||
----------------------------------------------------------------------------
|
||||
|
||||
You can prevent plugins from loading or unregister them::
|
||||
|
|
@ -253,7 +253,7 @@ in the `pytest repository <http://bitbucket.org/hpk42/pytest/>`_.
|
|||
py.test hook reference
|
||||
====================================
|
||||
|
||||
hook specification and validation
|
||||
Hook specification and validation
|
||||
-----------------------------------------
|
||||
|
||||
py.test calls hook functions to implement initialization, running,
|
||||
|
|
@ -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
|
||||
Initialisation, command line and configuration hooks
|
||||
--------------------------------------------------------------------
|
||||
|
||||
.. currentmodule:: _pytest.hookspec
|
||||
|
|
@ -277,7 +277,7 @@ initialisation, command line and configuration hooks
|
|||
.. autofunction:: pytest_configure
|
||||
.. autofunction:: pytest_unconfigure
|
||||
|
||||
generic "runtest" hooks
|
||||
Generic "runtest" hooks
|
||||
------------------------------
|
||||
|
||||
All all runtest related hooks receive a :py:class:`pytest.Item` object.
|
||||
|
|
@ -297,7 +297,7 @@ into interactive debugging when a test failure occurs.
|
|||
The :py:mod:`_pytest.terminal` reported specifically uses
|
||||
the reporting hook to print information about a test run.
|
||||
|
||||
collection hooks
|
||||
Collection hooks
|
||||
------------------------------
|
||||
|
||||
py.test calls the following hooks for collecting files and directories:
|
||||
|
|
@ -312,7 +312,7 @@ you can use the following hook:
|
|||
.. autofunction:: pytest_pycollect_makeitem
|
||||
|
||||
|
||||
reporting hooks
|
||||
Reporting hooks
|
||||
------------------------------
|
||||
|
||||
Session related reporting hooks:
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
|
||||
asserting deprecation and other warnings.
|
||||
Asserting deprecation and other warnings.
|
||||
=====================================================
|
||||
|
||||
recwarn function argument
|
||||
The recwarn function argument
|
||||
------------------------------------
|
||||
|
||||
You can use the ``recwarn`` funcarg to assert that code triggers
|
||||
|
|
@ -24,7 +24,7 @@ The ``recwarn`` function argument provides these methods:
|
|||
* ``pop(category=None)``: return last warning matching the category.
|
||||
* ``clear()``: clear list of warnings
|
||||
|
||||
ensuring a function triggers a deprecation warning
|
||||
Ensuring a function triggers a deprecation warning
|
||||
-------------------------------------------------------
|
||||
|
||||
You can also call a global helper for checking
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
.. _`skip and xfail`:
|
||||
|
||||
skip and xfail: dealing with tests that can not succeed
|
||||
Skip and xfail: dealing with tests that can not succeed
|
||||
=====================================================================
|
||||
|
||||
If you have test functions that cannot be run on certain platforms
|
||||
|
|
@ -62,7 +62,7 @@ decorator at module level like this::
|
|||
def test_function():
|
||||
...
|
||||
|
||||
skip all test functions of a class
|
||||
Skip all test functions of a class
|
||||
--------------------------------------
|
||||
|
||||
As with all function :ref:`marking <mark>` you can skip test functions at the
|
||||
|
|
@ -92,7 +92,7 @@ Using multiple "skipif" decorators on a single function is generally fine - it m
|
|||
|
||||
.. _xfail:
|
||||
|
||||
mark a test function as expected to fail
|
||||
Mark a test function as expected to fail
|
||||
-------------------------------------------------------
|
||||
|
||||
You can use the ``xfail`` marker to indicate that you
|
||||
|
|
@ -151,7 +151,7 @@ Running it with the report-on-xfail option gives this output::
|
|||
|
||||
.. _`evaluation of skipif/xfail conditions`:
|
||||
|
||||
evaluation of skipif/xfail expressions
|
||||
Evaluation of skipif/xfail expressions
|
||||
----------------------------------------------------
|
||||
|
||||
.. versionadded:: 2.0.2
|
||||
|
|
@ -174,7 +174,7 @@ which you might have added::
|
|||
...
|
||||
|
||||
|
||||
imperative xfail from within a test or setup function
|
||||
Imperative xfail from within a test or setup function
|
||||
------------------------------------------------------
|
||||
|
||||
If you cannot declare xfail-conditions at import time
|
||||
|
|
@ -186,7 +186,7 @@ within test or setup code. Example::
|
|||
pytest.xfail("unsupported configuration")
|
||||
|
||||
|
||||
skipping on a missing import dependency
|
||||
Skipping on a missing import dependency
|
||||
--------------------------------------------------
|
||||
|
||||
You can use the following import helper at module level
|
||||
|
|
@ -202,7 +202,7 @@ version number of a library::
|
|||
|
||||
The version will be read from the specified module's ``__version__`` attribute.
|
||||
|
||||
imperative skip from within a test or setup function
|
||||
Imperative skip from within a test or setup function
|
||||
------------------------------------------------------
|
||||
|
||||
If for some reason you cannot declare skip-conditions
|
||||
|
|
|
|||
|
|
@ -4,40 +4,40 @@ Talks and Tutorials
|
|||
|
||||
.. _`funcargs`: funcargs.html
|
||||
|
||||
tutorial examples and blog postings
|
||||
Tutorial examples and blog postings
|
||||
---------------------------------------------
|
||||
|
||||
.. _`tutorial1 repository`: http://bitbucket.org/hpk42/pytest-tutorial1/
|
||||
.. _`pycon 2010 tutorial PDF`: http://bitbucket.org/hpk42/pytest-tutorial1/raw/tip/pytest-basic.pdf
|
||||
|
||||
basic usage and funcargs:
|
||||
Basic usage and funcargs:
|
||||
|
||||
- `pycon 2010 tutorial PDF`_ and `tutorial1 repository`_
|
||||
|
||||
function arguments:
|
||||
Function arguments:
|
||||
|
||||
- :ref:`mysetup`
|
||||
- `application setup in test functions with funcargs`_
|
||||
- `monkey patching done right`_ (blog post, consult `monkeypatch
|
||||
plugin`_ for actual 1.0 API)
|
||||
|
||||
test parametrization:
|
||||
Test parametrization:
|
||||
|
||||
- `generating parametrized tests with funcargs`_
|
||||
- `test generators and cached setup`_
|
||||
- `parametrizing tests, generalized`_ (blog post)
|
||||
- `putting test-hooks into local or global plugins`_ (blog post)
|
||||
|
||||
assertion introspection
|
||||
Assertion introspection:
|
||||
|
||||
- `(07/2011) Behind the scenes of py.test's new assertion rewriting
|
||||
<http://pybites.blogspot.com/2011/07/behind-scenes-of-pytests-new-assertion.html>`_
|
||||
|
||||
distributed testing:
|
||||
Distributed testing:
|
||||
|
||||
- `simultaneously test your code on all platforms`_ (blog entry)
|
||||
|
||||
plugin specific examples:
|
||||
Plugin specific examples:
|
||||
|
||||
- `skipping slow tests by default in py.test`_ (blog entry)
|
||||
|
||||
|
|
@ -54,7 +54,7 @@ plugin specific examples:
|
|||
.. _`generating parametrized tests with funcargs`: funcargs.html#test-generators
|
||||
.. _`test generators and cached setup`: http://bruynooghe.blogspot.com/2010/06/pytest-test-generators-and-cached-setup.html
|
||||
|
||||
conference talks and tutorials
|
||||
Conference talks and tutorials
|
||||
----------------------------------------
|
||||
|
||||
- `ep2009-rapidtesting.pdf`_ tutorial slides (July 2009):
|
||||
|
|
|
|||
|
|
@ -1,10 +1,10 @@
|
|||
|
||||
.. _`tmpdir handling`:
|
||||
|
||||
temporary directories and files
|
||||
Temporary directories and files
|
||||
================================================
|
||||
|
||||
the 'tmpdir' test function argument
|
||||
The 'tmpdir' test function argument
|
||||
-----------------------------------
|
||||
|
||||
You can use the ``tmpdir`` function argument which will
|
||||
|
|
@ -51,7 +51,7 @@ Running this would result in a passed test except for the last
|
|||
|
||||
.. _`base temporary directory`:
|
||||
|
||||
the default base temporary directory
|
||||
The default base temporary directory
|
||||
-----------------------------------------------
|
||||
|
||||
Temporary directories are by default created as sub-directories of
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
|
||||
.. _`unittest.TestCase`:
|
||||
|
||||
unittest.TestCase support
|
||||
Support for unittest.TestCase
|
||||
=====================================================================
|
||||
|
||||
py.test has limited support for running Python `unittest.py style`_ tests.
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ Usage and Invocations
|
|||
|
||||
.. _cmdline:
|
||||
|
||||
calling pytest through ``python -m pytest``
|
||||
Calling pytest through ``python -m pytest``
|
||||
-----------------------------------------------------
|
||||
|
||||
.. versionadded:: 2.0
|
||||
|
|
@ -38,7 +38,7 @@ To stop the testing process after the first (N) failures::
|
|||
py.test -x # stop after first failure
|
||||
py.test -maxfail=2 # stop after two failures
|
||||
|
||||
specifying tests / selecting tests
|
||||
Specifying tests / selecting tests
|
||||
---------------------------------------------------
|
||||
|
||||
Several test run options::
|
||||
|
|
@ -98,7 +98,7 @@ can use a helper::
|
|||
In previous versions you could only enter PDB tracing if
|
||||
you disable capturing on the command line via ``py.test -s``.
|
||||
|
||||
creating JUnitXML format files
|
||||
Creating JUnitXML format files
|
||||
----------------------------------------------------
|
||||
|
||||
To create result files which can be read by Hudson_ or other Continuous
|
||||
|
|
@ -108,7 +108,7 @@ integration servers, use this invocation::
|
|||
|
||||
to create an XML file at ``path``.
|
||||
|
||||
creating resultlog format files
|
||||
Creating resultlog format files
|
||||
----------------------------------------------------
|
||||
|
||||
To create plain-text machine-readable result files you can issue::
|
||||
|
|
@ -121,7 +121,7 @@ by the `PyPy-test`_ web page to show test results over several revisions.
|
|||
.. _`PyPy-test`: http://codespeak.net:8099/summary
|
||||
|
||||
|
||||
send test report to pocoo pastebin service
|
||||
Sending test report to pocoo pastebin service
|
||||
-----------------------------------------------------
|
||||
|
||||
**Creating a URL for each test failure**::
|
||||
|
|
@ -138,7 +138,7 @@ for example ``-x`` if you only want to send one particular failure.
|
|||
|
||||
Currently only pasting to the http://paste.pocoo.org service is implemented.
|
||||
|
||||
calling pytest from Python code
|
||||
Calling pytest from Python code
|
||||
----------------------------------------------------
|
||||
|
||||
.. versionadded:: 2.0
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
.. _xunitsetup:
|
||||
|
||||
====================================
|
||||
extended xUnit style setup fixtures
|
||||
Extended xUnit style setup fixtures
|
||||
====================================
|
||||
|
||||
.. _`funcargs`: funcargs.html
|
||||
|
|
@ -16,7 +16,7 @@ before running a test function and ``teardown`` after it has finished.
|
|||
handling by optionally calling per-module and per-class hooks.
|
||||
|
||||
|
||||
module level setup/teardown
|
||||
Module level setup/teardown
|
||||
=============================================
|
||||
|
||||
If you have multiple test functions and test classes in a single
|
||||
|
|
@ -33,7 +33,7 @@ which will usually be called once for all the functions::
|
|||
with a setup_module method.
|
||||
"""
|
||||
|
||||
class level setup/teardown
|
||||
Class level setup/teardown
|
||||
=============================================
|
||||
|
||||
Similarly, the following methods are called at class level before
|
||||
|
|
@ -51,7 +51,7 @@ and after all test methods of the class are called::
|
|||
with a call to setup_class.
|
||||
"""
|
||||
|
||||
method and function level setup/teardown
|
||||
Method and function level setup/teardown
|
||||
=============================================
|
||||
|
||||
Similarly, the following methods are called around each method invocation::
|
||||
|
|
|
|||
Loading…
Reference in New Issue