floraachy/pytest2
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

remove trailing whitespace everywhere

Browse Source 
--HG--
branch : trunk
This commit is contained in:
holger krekel
2010-07-26 21:15:15 +02:00
parent 1693b9c407
commit 677f7c0a6a
219 changed files with 4400 additions and 4398 deletions
Download Patch File Download Diff File Expand all files Collapse all files
doc/test/plugin/capture.txt
+37 -37
View File
@@ -6,27 +6,27 @@ configurable per-test stdout/stderr capturing mechanisms.
.. contents::
:local:
This plugin captures stdout/stderr output for each test separately.
In case of test failures this captured output is shown grouped
togtther with the test.
This plugin captures stdout/stderr output for each test separately.
In case of test failures this captured output is shown grouped
togtther with the test.
The plugin also provides test function arguments that help to
assert stdout/stderr output from within your tests, see the
`funcarg example`_.
assert stdout/stderr output from within your tests, see the
`funcarg example`_.
Capturing of input/output streams during tests
Capturing of input/output streams during tests
---------------------------------------------------
By default ``sys.stdout`` and ``sys.stderr`` are substituted with
temporary streams during the execution of tests and setup/teardown code.
During the whole testing process it will re-use the same temporary
temporary streams during the execution of tests and setup/teardown code.
During the whole testing process it will re-use the same temporary
streams allowing to play well with the logging module which easily
takes ownership on these streams.
takes ownership on these streams.
Also, 'sys.stdin' is substituted with a file-like "null" object that
Also, 'sys.stdin' is substituted with a file-like "null" object that
does not return any values. This is to immediately error out
on tests that wait on reading something from stdin.
on tests that wait on reading something from stdin.
You can influence output capturing mechanisms from the command line::
@@ -39,34 +39,34 @@ If you set capturing values in a conftest file like this::
# conftest.py
option_capture = 'fd'
then all tests in that directory will execute with "fd" style capturing.
then all tests in that directory will execute with "fd" style capturing.
sys-level capturing
sys-level capturing
------------------------------------------
Capturing on 'sys' level means that ``sys.stdout`` and ``sys.stderr``
will be replaced with in-memory files (``py.io.TextIO`` to be precise)
Capturing on 'sys' level means that ``sys.stdout`` and ``sys.stderr``
will be replaced with in-memory files (``py.io.TextIO`` to be precise)
that capture writes and decode non-unicode strings to a unicode object
(using a default, usually, UTF-8, encoding).
(using a default, usually, UTF-8, encoding).
FD-level capturing and subprocesses
------------------------------------------
The ``fd`` based method means that writes going to system level files
based on the standard file descriptors will be captured, for example
writes such as ``os.write(1, 'hello')`` will be captured properly.
Capturing on fd-level will include output generated from
any subprocesses created during a test.
based on the standard file descriptors will be captured, for example
writes such as ``os.write(1, 'hello')`` will be captured properly.
Capturing on fd-level will include output generated from
any subprocesses created during a test.
.. _`funcarg example`:
Example Usage of the capturing Function arguments
---------------------------------------------------
You can use the `capsys funcarg`_ and `capfd funcarg`_ to
You can use the `capsys funcarg`_ and `capfd funcarg`_ to
capture writes to stdout and stderr streams. Using the
funcargs frees your test from having to care about setting/resetting
the old streams and also interacts well with py.test's own
funcargs frees your test from having to care about setting/resetting
the old streams and also interacts well with py.test's own
per-test capturing. Here is an example test function:
.. sourcecode:: python
@@ -79,12 +79,12 @@ per-test capturing. Here is an example test function:
assert err == "world\n"
print "next"
out, err = capsys.readouterr()
assert out == "next\n"
assert out == "next\n"
The ``readouterr()`` call snapshots the output so far -
and capturing will be continued. After the test
function finishes the original streams will
be restored. If you want to capture on
The ``readouterr()`` call snapshots the output so far -
and capturing will be continued. After the test
function finishes the original streams will
be restored. If you want to capture on
the filedescriptor level you can use the ``capfd`` function
argument which offers the same interface.
@@ -94,9 +94,9 @@ argument which offers the same interface.
the 'capsys' test function argument
-----------------------------------
captures writes to sys.stdout/sys.stderr and makes
them available successively via a ``capsys.readouterr()`` method
which returns a ``(out, err)`` tuple of captured snapshot strings.
captures writes to sys.stdout/sys.stderr and makes
them available successively via a ``capsys.readouterr()`` method
which returns a ``(out, err)`` tuple of captured snapshot strings.
.. _`capfd funcarg`:
@@ -104,11 +104,11 @@ which returns a ``(out, err)`` tuple of captured snapshot strings.
the 'capfd' test function argument
----------------------------------
captures writes to file descriptors 1 and 2 and makes
snapshotted ``(out, err)`` string tuples available
captures writes to file descriptors 1 and 2 and makes
snapshotted ``(out, err)`` string tuples available
via the ``capsys.readouterr()`` method. If the underlying
platform does not have ``os.dup`` (e.g. Jython) tests using
this funcarg will automatically skip.
this funcarg will automatically skip.
command line options
--------------------
@@ -123,10 +123,10 @@ Start improving this plugin in 30 seconds
=========================================
1. Download `pytest_capture.py`_ plugin source code
2. put it somewhere as ``pytest_capture.py`` into your import path
1. Download `pytest_capture.py`_ plugin source code
2. put it somewhere as ``pytest_capture.py`` into your import path
3. a subsequent ``py.test`` run will use your local version
Checkout customize_, other plugins_ or `get in contact`_.
Checkout customize_, other plugins_ or `get in contact`_.
.. include:: links.txt
doc/test/plugin/capturelog.txt
+2 -2
View File
@@ -9,10 +9,10 @@ capture output of logging module.
Installation
------------
You can install the `pytest-capturelog pypi`_ package
You can install the `pytest-capturelog pypi`_ package
with pip::
pip install pytest-capturelog
pip install pytest-capturelog
or with easy install::
doc/test/plugin/coverage.txt
+1 -1
View File
@@ -6,7 +6,7 @@ Write and report coverage data with the 'coverage' package.
.. contents::
:local:
Original code by Ross Lawley.
Original code by Ross Lawley.
Requires Ned Batchelder's excellent coverage:
http://nedbatchelder.com/code/coverage/
doc/test/plugin/doctest.txt
+6 -6
View File
@@ -9,7 +9,7 @@ collect and execute doctests from modules and test files.
Usage
-------------
By default all files matching the ``test*.txt`` pattern will
By default all files matching the ``test*.txt`` pattern will
be run through the python standard ``doctest`` module. Issue::
py.test --doctest-glob='*.rst'
@@ -19,10 +19,10 @@ tests in all python modules (including regular python test modules)::
py.test --doctest-modules
You can also make these changes permanent in your project by
You can also make these changes permanent in your project by
putting them into a conftest.py file like this::
# content of conftest.py
# content of conftest.py
option_doctestmodules = True
option_doctestglob = "*.rst"
@@ -39,10 +39,10 @@ Start improving this plugin in 30 seconds
=========================================
1. Download `pytest_doctest.py`_ plugin source code
2. put it somewhere as ``pytest_doctest.py`` into your import path
1. Download `pytest_doctest.py`_ plugin source code
2. put it somewhere as ``pytest_doctest.py`` into your import path
3. a subsequent ``py.test`` run will use your local version
Checkout customize_, other plugins_ or `get in contact`_.
Checkout customize_, other plugins_ or `get in contact`_.
.. include:: links.txt
doc/test/plugin/figleaf.txt
+1 -1
View File
@@ -14,7 +14,7 @@ after pip or easy_install mediated installation of ``pytest-figleaf`` you can ty
py.test --figleaf [...]
to enable figleaf coverage in your test run. A default ".figleaf" data file
and "html" directory will be created. You can use ``--fig-data``
and "html" directory will be created. You can use ``--fig-data``
and ``fig-html`` to modify the paths.
command line options
doc/test/plugin/genscript.txt
+3 -3
View File
@@ -19,10 +19,10 @@ Start improving this plugin in 30 seconds
=========================================
1. Download `pytest_genscript.py`_ plugin source code
2. put it somewhere as ``pytest_genscript.py`` into your import path
1. Download `pytest_genscript.py`_ plugin source code
2. put it somewhere as ``pytest_genscript.py`` into your import path
3. a subsequent ``py.test`` run will use your local version
Checkout customize_, other plugins_ or `get in contact`_.
Checkout customize_, other plugins_ or `get in contact`_.
.. include:: links.txt
doc/test/plugin/helpconfig.txt
+4 -4
View File
@@ -19,7 +19,7 @@ command line options
``--traceconfig``
trace considerations of conftest.py files.
``--nomagic``
don't reinterpret asserts, no traceback cutting.
don't reinterpret asserts, no traceback cutting.
``--debug``
generate and show internal debugging information.
``--help-config``
@@ -29,10 +29,10 @@ Start improving this plugin in 30 seconds
=========================================
1. Download `pytest_helpconfig.py`_ plugin source code
2. put it somewhere as ``pytest_helpconfig.py`` into your import path
1. Download `pytest_helpconfig.py`_ plugin source code
2. put it somewhere as ``pytest_helpconfig.py`` into your import path
3. a subsequent ``py.test`` run will use your local version
Checkout customize_, other plugins_ or `get in contact`_.
Checkout customize_, other plugins_ or `get in contact`_.
.. include:: links.txt
doc/test/plugin/hooklog.txt
+3 -3
View File
@@ -19,10 +19,10 @@ Start improving this plugin in 30 seconds
=========================================
1. Download `pytest_hooklog.py`_ plugin source code
2. put it somewhere as ``pytest_hooklog.py`` into your import path
1. Download `pytest_hooklog.py`_ plugin source code
2. put it somewhere as ``pytest_hooklog.py`` into your import path
3. a subsequent ``py.test`` run will use your local version
Checkout customize_, other plugins_ or `get in contact`_.
Checkout customize_, other plugins_ or `get in contact`_.
.. include:: links.txt
doc/test/plugin/hookspec.txt
+75 -75
View File
@@ -5,202 +5,202 @@ hook specification sourcecode
.. sourcecode:: python
"""
hook specifications for py.test plugins
hook specifications for py.test plugins
"""
# -------------------------------------------------------------------------
# Command line and configuration
# Command line and configuration
# -------------------------------------------------------------------------
def pytest_namespace():
"return dict of name->object which will get stored at py.test. namespace"
def pytest_addoption(parser):
"add optparse-style options via parser.addoption."
def pytest_addhooks(pluginmanager):
"add hooks via pluginmanager.registerhooks(module)"
def pytest_configure(config):
""" called after command line options have been parsed.
and all plugins and initial conftest files been loaded.
""" called after command line options have been parsed.
and all plugins and initial conftest files been loaded.
"""
def pytest_unconfigure(config):
""" called before test process is exited. """
# -------------------------------------------------------------------------
# collection hooks
# -------------------------------------------------------------------------
def pytest_ignore_collect(path, config):
""" return true value to prevent considering this path for collection.
""" return true value to prevent considering this path for collection.
This hook is consulted for all files and directories prior to considering
collection hooks.
collection hooks.
"""
pytest_ignore_collect.firstresult = True
def pytest_collect_directory(path, parent):
""" return Collection node or None for the given path. """
pytest_collect_directory.firstresult = True
def pytest_collect_file(path, parent):
""" return Collection node or None for the given path. """
def pytest_collectstart(collector):
""" collector starts collecting. """
def pytest_collectreport(report):
""" collector finished collecting. """
def pytest_deselected(items):
""" called for test items deselected by keyword. """
def pytest_make_collect_report(collector):
""" perform a collection and return a collection. """
""" perform a collection and return a collection. """
pytest_make_collect_report.firstresult = True
# XXX rename to item_collected()? meaning in distribution context?
# XXX rename to item_collected()? meaning in distribution context?
def pytest_itemstart(item, node=None):
""" test item gets collected. """
# -------------------------------------------------------------------------
# Python test function related hooks
# -------------------------------------------------------------------------
def pytest_pycollect_makemodule(path, parent):
""" return a Module collector or None for the given path.
This hook will be called for each matching test module path.
The pytest_collect_file hook needs to be used if you want to
""" return a Module collector or None for the given path.
This hook will be called for each matching test module path.
The pytest_collect_file hook needs to be used if you want to
create test modules for files that do not match as a test module.
"""
pytest_pycollect_makemodule.firstresult = True
def pytest_pycollect_makeitem(collector, name, obj):
""" return custom item/collector for a python object in a module, or None. """
pytest_pycollect_makeitem.firstresult = True
def pytest_pyfunc_call(pyfuncitem):
""" call underlying test function. """
pytest_pyfunc_call.firstresult = True
def pytest_generate_tests(metafunc):
""" generate (multiple) parametrized calls to a test function."""
# -------------------------------------------------------------------------
# generic runtest related hooks
# generic runtest related hooks
# -------------------------------------------------------------------------
def pytest_runtest_protocol(item):
""" implement fixture, run and report about the given test item. """
pytest_runtest_protocol.firstresult = True
def pytest_runtest_setup(item):
""" called before pytest_runtest_call(). """
""" called before pytest_runtest_call(). """
def pytest_runtest_call(item):
""" execute test item. """
""" execute test item. """
def pytest_runtest_teardown(item):
""" called after pytest_runtest_call(). """
""" called after pytest_runtest_call(). """
def pytest_runtest_makereport(item, call):
""" make a test report for the given item and call outcome. """
pytest_runtest_makereport.firstresult = True
def pytest_runtest_logreport(report):
""" process item test report. """
""" process item test report. """
# special handling for final teardown - somewhat internal for now
def pytest__teardown_final(session):
""" called before test session finishes. """
pytest__teardown_final.firstresult = True
def pytest__teardown_final_logerror(report):
""" called if runtest_teardown_final failed. """
""" called if runtest_teardown_final failed. """
# -------------------------------------------------------------------------
# test session related hooks
# test session related hooks
# -------------------------------------------------------------------------
def pytest_sessionstart(session):
""" before session.main() is called. """
def pytest_sessionfinish(session, exitstatus):
""" whole test run finishes. """
# -------------------------------------------------------------------------
# hooks for influencing reporting (invoked from pytest_terminal)
# -------------------------------------------------------------------------
def pytest_report_header(config):
""" return a string to be displayed as header info for terminal reporting."""
def pytest_report_teststatus(report):
""" return result-category, shortletter and verbose word for reporting."""
pytest_report_teststatus.firstresult = True
def pytest_terminal_summary(terminalreporter):
""" add additional section in terminal summary reporting. """
def pytest_report_iteminfo(item):
""" return (fspath, lineno, name) for the item.
the information is used for result display and to sort tests
"""
pytest_report_iteminfo.firstresult = True
# -------------------------------------------------------------------------
# doctest hooks
# doctest hooks
# -------------------------------------------------------------------------
def pytest_doctest_prepare_content(content):
""" return processed content for a given doctest"""
pytest_doctest_prepare_content.firstresult = True
# -------------------------------------------------------------------------
# error handling and internal debugging hooks
# error handling and internal debugging hooks
# -------------------------------------------------------------------------
def pytest_plugin_registered(plugin, manager):
""" a new py lib plugin got registered. """
def pytest_plugin_unregistered(plugin):
""" a py lib plugin got unregistered. """
def pytest_internalerror(excrepr):
""" called for internal errors. """
def pytest_keyboard_interrupt(excinfo):
""" called for keyboard interrupt. """
def pytest_trace(category, msg):
""" called for debug info. """
""" called for debug info. """
hook specification sourcecode
=============================
.. sourcecode:: python
def pytest_gwmanage_newgateway(gateway, platinfo):
""" called on new raw gateway creation. """
""" called on new raw gateway creation. """
def pytest_gwmanage_rsyncstart(source, gateways):
""" called before rsyncing a directory to remote gateways takes place. """
def pytest_gwmanage_rsyncfinish(source, gateways):
""" called after rsyncing a directory to remote gateways takes place. """
def pytest_configure_node(node):
""" configure node information before it gets instantiated. """
def pytest_testnodeready(node):
""" Test Node is ready to operate. """
def pytest_testnodedown(node, error):
""" Test Node is down. """
def pytest_rescheduleitems(items):
""" reschedule Items from a node that went down. """
doc/test/plugin/junitxml.txt
+3 -3
View File
@@ -21,10 +21,10 @@ Start improving this plugin in 30 seconds
=========================================
1. Download `pytest_junitxml.py`_ plugin source code
2. put it somewhere as ``pytest_junitxml.py`` into your import path
1. Download `pytest_junitxml.py`_ plugin source code
2. put it somewhere as ``pytest_junitxml.py`` into your import path
3. a subsequent ``py.test`` run will use your local version
Checkout customize_, other plugins_ or `get in contact`_.
Checkout customize_, other plugins_ or `get in contact`_.
.. include:: links.txt
doc/test/plugin/mark.txt
+12 -12
View File
@@ -7,18 +7,18 @@ generic mechanism for marking python functions.
:local:
By using the ``py.test.mark`` helper you can instantiate
decorators that will set named meta data on test functions.
decorators that will set named meta data on test functions.
Marking a single function
Marking a single function
----------------------------------------------------
You can "mark" a test function with meta data like this::
@py.test.mark.webtest
def test_send_http():
...
...
This will set a "Marker" instance as a function attribute named "webtest".
This will set a "Marker" instance as a function attribute named "webtest".
You can also specify parametrized meta data like this::
@py.test.mark.webtest(firefox=30)
@@ -39,7 +39,7 @@ and later access it with ``test_receive.webtest.args[0] == 'triangular``.
.. _`scoped-marking`:
Marking whole classes or modules
Marking whole classes or modules
----------------------------------------------------
If you are programming with Python2.6 you may use ``py.test.mark`` decorators
@@ -53,9 +53,9 @@ with classes to apply markers to all its test methods::
...
This is equivalent to directly applying the decorator to the
two test functions.
two test functions.
To remain compatible with Python2.5 you can also set a
To remain compatible with Python2.5 you can also set a
``pytestmark`` attribute on a TestClass like this::
import py
@@ -75,8 +75,8 @@ You can also set a module level marker::
import py
pytestmark = py.test.mark.webtest
in which case it will be applied to all functions and
methods defined in the module.
in which case it will be applied to all functions and
methods defined in the module.
Using "-k MARKNAME" to select tests
----------------------------------------------------
@@ -90,10 +90,10 @@ Start improving this plugin in 30 seconds
=========================================
1. Download `pytest_mark.py`_ plugin source code
2. put it somewhere as ``pytest_mark.py`` into your import path
1. Download `pytest_mark.py`_ plugin source code
2. put it somewhere as ``pytest_mark.py`` into your import path
3. a subsequent ``py.test`` run will use your local version
Checkout customize_, other plugins_ or `get in contact`_.
Checkout customize_, other plugins_ or `get in contact`_.
.. include:: links.txt
doc/test/plugin/monkeypatch.txt
+29 -29
View File
@@ -6,54 +6,54 @@ safely patch object attributes, dicts and environment variables.
.. contents::
:local:
Usage
Usage
----------------
Use the `monkeypatch funcarg`_ to tweak your global test environment
for running a particular test. You can safely set/del an attribute,
Use the `monkeypatch funcarg`_ to tweak your global test environment
for running a particular test. You can safely set/del an attribute,
dictionary item or environment variable by respective methods
on the monkeypatch funcarg. If you want e.g. to set an ENV1 variable
and have os.path.expanduser return a particular directory, you can
on the monkeypatch funcarg. If you want e.g. to set an ENV1 variable
and have os.path.expanduser return a particular directory, you can
write it down like this:
.. sourcecode:: python
.. sourcecode:: python
def test_mytest(monkeypatch):
monkeypatch.setenv('ENV1', 'myval')
monkeypatch.setattr(os.path, 'expanduser', lambda x: '/tmp/xyz')
... # your test code that uses those patched values implicitely
After the test function finished all modifications will be undone,
because the ``monkeypatch.undo()`` method is registered as a finalizer.
After the test function finished all modifications will be undone,
because the ``monkeypatch.undo()`` method is registered as a finalizer.
``monkeypatch.setattr/delattr/delitem/delenv()`` all
by default raise an Exception if the target does not exist.
Pass ``raising=False`` if you want to skip this check.
``monkeypatch.setattr/delattr/delitem/delenv()`` all
by default raise an Exception if the target does not exist.
Pass ``raising=False`` if you want to skip this check.
prepending to PATH or other environment variables
prepending to PATH or other environment variables
---------------------------------------------------------
To prepend a value to an already existing environment parameter:
.. sourcecode:: python
.. sourcecode:: python
def test_mypath_finding(monkeypatch):
monkeypatch.setenv('PATH', 'x/y', prepend=":")
# in bash language: export PATH=x/y:$PATH
# in bash language: export PATH=x/y:$PATH
calling "undo" finalization explicitely
-----------------------------------------
At the end of function execution py.test invokes
a teardown hook which undoes all monkeypatch changes.
If you do not want to wait that long you can call
a teardown hook which undoes all monkeypatch changes.
If you do not want to wait that long you can call
finalization explicitely::
monkeypatch.undo()
monkeypatch.undo()
This will undo previous changes. This call consumes the
undo stack. Calling it a second time has no effect unless
you start monkeypatching after the undo call.
you start monkeypatching after the undo call.
.. _`monkeypatch blog post`: http://tetamap.wordpress.com/2009/03/03/monkeypatching-in-unit-tests-done-right/
@@ -63,30 +63,30 @@ you start monkeypatching after the undo call.
the 'monkeypatch' test function argument
----------------------------------------
The returned ``monkeypatch`` funcarg provides these
The returned ``monkeypatch`` funcarg provides these
helper methods to modify objects, dictionaries or os.environ::
monkeypatch.setattr(obj, name, value, raising=True)
monkeypatch.setattr(obj, name, value, raising=True)
monkeypatch.delattr(obj, name, raising=True)
monkeypatch.setitem(mapping, name, value)
monkeypatch.setitem(mapping, name, value)
monkeypatch.delitem(obj, name, raising=True)
monkeypatch.setenv(name, value, prepend=False)
monkeypatch.setenv(name, value, prepend=False)
monkeypatch.delenv(name, value, raising=True)
monkeypatch.syspath_prepend(path)
All modifications will be undone when the requesting
test function finished its execution. The ``raising``
parameter determines if a KeyError or AttributeError
will be raised if the set/deletion operation has no target.
All modifications will be undone when the requesting
test function finished its execution. The ``raising``
parameter determines if a KeyError or AttributeError
will be raised if the set/deletion operation has no target.
Start improving this plugin in 30 seconds
=========================================
1. Download `pytest_monkeypatch.py`_ plugin source code
2. put it somewhere as ``pytest_monkeypatch.py`` into your import path
1. Download `pytest_monkeypatch.py`_ plugin source code
2. put it somewhere as ``pytest_monkeypatch.py`` into your import path
3. a subsequent ``py.test`` run will use your local version
Checkout customize_, other plugins_ or `get in contact`_.
Checkout customize_, other plugins_ or `get in contact`_.
.. include:: links.txt
doc/test/plugin/nose.txt
+13 -13
View File
@@ -6,8 +6,8 @@ nose-compatibility plugin: allow to run nose test suites natively.
.. contents::
:local:
This is an experimental plugin for allowing to run tests written
in 'nosetests style with py.test.
This is an experimental plugin for allowing to run tests written
in 'nosetests style with py.test.
Usage
-------------
@@ -17,28 +17,28 @@ type::
py.test # instead of 'nosetests'
and you should be able to run nose style tests and at the same
time can make full use of py.test's capabilities.
time can make full use of py.test's capabilities.
Supported nose Idioms
----------------------
* setup and teardown at module/class/method level
* SkipTest exceptions and markers
* SkipTest exceptions and markers
* setup/teardown decorators
* yield-based tests and their setup
* general usage of nose utilities
* yield-based tests and their setup
* general usage of nose utilities
Unsupported idioms / issues
----------------------------------
- nose-style doctests are not collected and executed correctly,
also fixtures don't work.
also fixtures don't work.
- no nose-configuration is recognized
- no nose-configuration is recognized
If you find other issues or have suggestions please run::
If you find other issues or have suggestions please run::
py.test --pastebin=all
py.test --pastebin=all
and send the resulting URL to a py.test contact channel,
at best to the mailing list.
@@ -47,10 +47,10 @@ Start improving this plugin in 30 seconds
=========================================
1. Download `pytest_nose.py`_ plugin source code
2. put it somewhere as ``pytest_nose.py`` into your import path
1. Download `pytest_nose.py`_ plugin source code
2. put it somewhere as ``pytest_nose.py`` into your import path
3. a subsequent ``py.test`` run will use your local version
Checkout customize_, other plugins_ or `get in contact`_.
Checkout customize_, other plugins_ or `get in contact`_.
.. include:: links.txt
doc/test/plugin/oejskit.txt
+2 -2
View File
@@ -4,9 +4,9 @@ pytest_oejskit plugin (EXTERNAL)
The `oejskit`_ offers a py.test plugin for running Javascript tests in life browers. Running inside the browsers comes with some speed cost, on the other hand it means for example the code is tested against the real-word DOM implementations.
The approach enables to write integration tests such that the JavaScript code is tested against server-side Python code mocked as necessary. Any server-side framework that can already be exposed through WSGI (or for which a subset of WSGI can be written to accommodate the jskit own needs) can play along.
For more info and download please visit the `oejskit PyPI`_ page.
For more info and download please visit the `oejskit PyPI`_ page.
.. _`oejskit`:
.. _`oejskit`:
.. _`oejskit PyPI`: http://pypi.python.org/pypi/oejskit
.. source link 'http://bitbucket.org/pedronis/js-infrastructure/src/tip/pytest_jstests.py',
doc/test/plugin/pastebin.txt
+6 -6
View File
@@ -11,15 +11,15 @@ Usage
**Creating a URL for each test failure**::
py.test --pastebin=failed
py.test --pastebin=failed
This will submit test run information to a remote Paste service and
provide a URL for each failure. You may select tests as usual or add
for example ``-x`` if you only want to send one particular failure.
for example ``-x`` if you only want to send one particular failure.
**Creating a URL for a whole test session log**::
py.test --pastebin=all
py.test --pastebin=all
Currently only pasting to the http://paste.pocoo.org service is implemented.
@@ -34,10 +34,10 @@ Start improving this plugin in 30 seconds
=========================================
1. Download `pytest_pastebin.py`_ plugin source code
2. put it somewhere as ``pytest_pastebin.py`` into your import path
1. Download `pytest_pastebin.py`_ plugin source code
2. put it somewhere as ``pytest_pastebin.py`` into your import path
3. a subsequent ``py.test`` run will use your local version
Checkout customize_, other plugins_ or `get in contact`_.
Checkout customize_, other plugins_ or `get in contact`_.
.. include:: links.txt
doc/test/plugin/pdb.txt
+3 -3
View File
@@ -19,10 +19,10 @@ Start improving this plugin in 30 seconds
=========================================
1. Download `pytest_pdb.py`_ plugin source code
2. put it somewhere as ``pytest_pdb.py`` into your import path
1. Download `pytest_pdb.py`_ plugin source code
2. put it somewhere as ``pytest_pdb.py`` into your import path
3. a subsequent ``py.test`` run will use your local version
Checkout customize_, other plugins_ or `get in contact`_.
Checkout customize_, other plugins_ or `get in contact`_.
.. include:: links.txt
doc/test/plugin/recwarn.txt
+7 -7
View File
@@ -6,10 +6,10 @@ helpers for asserting deprecation and other warnings.
.. contents::
:local:
Example usage
Example usage
---------------------
You can use the ``recwarn`` funcarg to track
You can use the ``recwarn`` funcarg to track
warnings within a test function:
.. sourcecode:: python
@@ -30,7 +30,7 @@ warning:
.. sourcecode:: python
import py
def test_global():
py.test.deprecated_call(myfunction, 17)
@@ -43,16 +43,16 @@ the 'recwarn' test function argument
Return a WarningsRecorder instance that provides these methods:
* ``pop(category=None)``: return last warning matching the category.
* ``clear()``: clear list of warnings
* ``clear()``: clear list of warnings
Start improving this plugin in 30 seconds
=========================================
1. Download `pytest_recwarn.py`_ plugin source code
2. put it somewhere as ``pytest_recwarn.py`` into your import path
1. Download `pytest_recwarn.py`_ plugin source code
2. put it somewhere as ``pytest_recwarn.py`` into your import path
3. a subsequent ``py.test`` run will use your local version
Checkout customize_, other plugins_ or `get in contact`_.
Checkout customize_, other plugins_ or `get in contact`_.
.. include:: links.txt
doc/test/plugin/restdoc.txt
+3 -3
View File
@@ -23,10 +23,10 @@ Start improving this plugin in 30 seconds
=========================================
1. Download `pytest_restdoc.py`_ plugin source code
2. put it somewhere as ``pytest_restdoc.py`` into your import path
1. Download `pytest_restdoc.py`_ plugin source code
2. put it somewhere as ``pytest_restdoc.py`` into your import path
3. a subsequent ``py.test`` run will use your local version
Checkout customize_, other plugins_ or `get in contact`_.
Checkout customize_, other plugins_ or `get in contact`_.
.. include:: links.txt
doc/test/plugin/resultlog.txt
+5 -5
View File
@@ -6,8 +6,8 @@ non-xml machine-readable logging of test results.
.. contents::
:local:
Useful for buildbot integration code. See the `PyPy-test`_
web page for post-processing.
Useful for buildbot integration code. See the `PyPy-test`_
web page for post-processing.
.. _`PyPy-test`: http://codespeak.net:8099/summary
@@ -22,10 +22,10 @@ Start improving this plugin in 30 seconds
=========================================
1. Download `pytest_resultlog.py`_ plugin source code
2. put it somewhere as ``pytest_resultlog.py`` into your import path
1. Download `pytest_resultlog.py`_ plugin source code
2. put it somewhere as ``pytest_resultlog.py`` into your import path
3. a subsequent ``py.test`` run will use your local version
Checkout customize_, other plugins_ or `get in contact`_.
Checkout customize_, other plugins_ or `get in contact`_.
.. include:: links.txt
doc/test/plugin/skipping.txt
+23 -23
View File
@@ -6,21 +6,21 @@ advanced skipping for python test functions, classes or modules.
.. contents::
:local:
With this plugin you can mark test functions for conditional skipping
With this plugin you can mark test functions for conditional skipping
or as "xfail", expected-to-fail. Skipping a test will avoid running it
while xfail-marked tests will run and result in an inverted outcome:
a pass becomes a failure and a fail becomes a semi-passing one.
a pass becomes a failure and a fail becomes a semi-passing one.
The need for skipping a test is usually connected to a condition.
The need for skipping a test is usually connected to a condition.
If a test fails under all conditions then it's probably better
to mark your test as 'xfail'.
to mark your test as 'xfail'.
By passing ``-rxs`` to the terminal reporter you will see extra
summary information on skips and xfail-run tests at the end of a test run.
summary information on skips and xfail-run tests at the end of a test run.
.. _skipif:
Skipping a single function
Skipping a single function
-------------------------------------------
Here is an example for marking a test function to be skipped
@@ -30,17 +30,17 @@ when run on a Python3 interpreter::
def test_function():
...
During test function setup the skipif condition is
During test function setup the skipif condition is
evaluated by calling ``eval(expr, namespace)``. The namespace
contains the ``sys`` and ``os`` modules and the test
``config`` object. The latter allows you to skip based
contains the ``sys`` and ``os`` modules and the test
``config`` object. The latter allows you to skip based
on a test configuration value e.g. like this::
@py.test.mark.skipif("not config.getvalue('db')")
def test_function(...):
...
Create a shortcut for your conditional skip decorator
Create a shortcut for your conditional skip decorator
at module level like this::
win32only = py.test.mark.skipif("sys.platform != 'win32'")
@@ -50,34 +50,34 @@ at module level like this::
...
skip groups of test functions
skip groups of test functions
--------------------------------------
As with all metadata function marking you can do it at
`whole class- or module level`_. Here is an example
`whole class- or module level`_. Here is an example
for skipping all methods of a test class based on platform::
class TestPosixCalls:
pytestmark = py.test.mark.skipif("sys.platform == 'win32'")
def test_function(self):
# will not be setup or run under 'win32' platform
#
The ``pytestmark`` decorator will be applied to each test function.
If your code targets python2.6 or above you can equivalently use
If your code targets python2.6 or above you can equivalently use
the skipif decorator on classes::
@py.test.mark.skipif("sys.platform == 'win32'")
class TestPosixCalls:
def test_function(self):
# will not be setup or run under 'win32' platform
#
It is fine in general to apply multiple "skipif" decorators
on a single function - this means that if any of the conditions
apply the function will be skipped.
apply the function will be skipped.
.. _`whole class- or module level`: mark.html#scoped-marking
@@ -87,7 +87,7 @@ mark a test function as **expected to fail**
-------------------------------------------------------
You can use the ``xfail`` marker to indicate that you
expect the test to fail::
expect the test to fail::
@py.test.mark.xfail
def test_function():
@@ -116,7 +116,7 @@ imperative xfail from within a test or setup function
------------------------------------------------------
If you cannot declare xfail-conditions at import time
you can also imperatively produce an XFail-outcome from
you can also imperatively produce an XFail-outcome from
within test or setup code. Example::
def test_function():
@@ -127,7 +127,7 @@ within test or setup code. Example::
skipping on a missing import dependency
--------------------------------------------------
You can use the following import helper at module level
You can use the following import helper at module level
or within a test or test setup function::
docutils = py.test.importorskip("docutils")
@@ -144,7 +144,7 @@ imperative skip from within a test or setup function
------------------------------------------------------
If for some reason you cannot declare skip-conditions
you can also imperatively produce a Skip-outcome from
you can also imperatively produce a Skip-outcome from
within test or setup code. Example::
def test_function():
@@ -162,10 +162,10 @@ Start improving this plugin in 30 seconds
=========================================
1. Download `pytest_skipping.py`_ plugin source code
2. put it somewhere as ``pytest_skipping.py`` into your import path
1. Download `pytest_skipping.py`_ plugin source code
2. put it somewhere as ``pytest_skipping.py`` into your import path
3. a subsequent ``py.test`` run will use your local version
Checkout customize_, other plugins_ or `get in contact`_.
Checkout customize_, other plugins_ or `get in contact`_.
.. include:: links.txt
doc/test/plugin/terminal.txt
+3 -3
View File
@@ -31,10 +31,10 @@ Start improving this plugin in 30 seconds
=========================================
1. Download `pytest_terminal.py`_ plugin source code
2. put it somewhere as ``pytest_terminal.py`` into your import path
1. Download `pytest_terminal.py`_ plugin source code
2. put it somewhere as ``pytest_terminal.py`` into your import path
3. a subsequent ``py.test`` run will use your local version
Checkout customize_, other plugins_ or `get in contact`_.
Checkout customize_, other plugins_ or `get in contact`_.
.. include:: links.txt
doc/test/plugin/tmpdir.txt
+4 -4
View File
@@ -23,16 +23,16 @@ return a temporary directory path object
unique to each test function invocation,
created as a sub directory of the base temporary
directory. The returned object is a `py.path.local`_
path object.
path object.
Start improving this plugin in 30 seconds
=========================================
1. Download `pytest_tmpdir.py`_ plugin source code
2. put it somewhere as ``pytest_tmpdir.py`` into your import path
1. Download `pytest_tmpdir.py`_ plugin source code
2. put it somewhere as ``pytest_tmpdir.py`` into your import path
3. a subsequent ``py.test`` run will use your local version
Checkout customize_, other plugins_ or `get in contact`_.
Checkout customize_, other plugins_ or `get in contact`_.
.. include:: links.txt
doc/test/plugin/unittest.txt
+7 -7
View File
@@ -9,12 +9,12 @@ automatically discover and run traditional "unittest.py" style tests.
Usage
----------------
This plugin collects and runs Python `unittest.py style`_ tests.
It will automatically collect ``unittest.TestCase`` subclasses
This plugin collects and runs Python `unittest.py style`_ tests.
It will automatically collect ``unittest.TestCase`` subclasses
and their ``test`` methods from the test modules of a project
(usually following the ``test_*.py`` pattern).
(usually following the ``test_*.py`` pattern).
This plugin is enabled by default.
This plugin is enabled by default.
.. _`unittest.py style`: http://docs.python.org/library/unittest.html
@@ -22,10 +22,10 @@ Start improving this plugin in 30 seconds
=========================================
1. Download `pytest_unittest.py`_ plugin source code
2. put it somewhere as ``pytest_unittest.py`` into your import path
1. Download `pytest_unittest.py`_ plugin source code
2. put it somewhere as ``pytest_unittest.py`` into your import path
3. a subsequent ``py.test`` run will use your local version
Checkout customize_, other plugins_ or `get in contact`_.
Checkout customize_, other plugins_ or `get in contact`_.
.. include:: links.txt
doc/test/plugin/xdist.txt
+32 -32
View File
@@ -6,24 +6,24 @@ loop on failing tests, distribute test runs to CPUs and hosts.
.. contents::
:local:
The `pytest-xdist`_ plugin extends py.test with some unique
The `pytest-xdist`_ plugin extends py.test with some unique
test execution modes:
* Looponfail: run your tests repeatedly in a subprocess. After each run py.test
waits until a file in your project changes and then re-runs the previously
failing tests. This is repeated until all tests pass after which again
a full run is performed.
a full run is performed.
* Load-balancing: if you have multiple CPUs or hosts you can use
those for a combined test run. This allows to speed up
development or to use special resources of remote machines.
those for a combined test run. This allows to speed up
development or to use special resources of remote machines.
* Multi-Platform coverage: you can specify different Python interpreters
or different platforms and run tests in parallel on all of them.
or different platforms and run tests in parallel on all of them.
Before running tests remotely, ``py.test`` efficiently synchronizes your
program source code to the remote place. All test results
are reported back and displayed to your local test session.
Before running tests remotely, ``py.test`` efficiently synchronizes your
program source code to the remote place. All test results
are reported back and displayed to your local test session.
You may specify different Python versions and interpreters.
.. _`pytest-xdist`: http://pypi.python.org/pypi/pytest-xdist
@@ -38,11 +38,11 @@ To send tests to multiple CPUs, type::
py.test -n NUM
Especially for longer running tests or tests requiring
a lot of IO this can lead to considerable speed ups.
Especially for longer running tests or tests requiring
a lot of IO this can lead to considerable speed ups.
Running tests in a Python subprocess
Running tests in a Python subprocess
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
To instantiate a python2.4 sub process and send tests to it, you may type::
@@ -50,51 +50,51 @@ To instantiate a python2.4 sub process and send tests to it, you may type::
py.test -d --tx popen//python=python2.4
This will start a subprocess which is run with the "python2.4"
Python interpreter, found in your system binary lookup path.
Python interpreter, found in your system binary lookup path.
If you prefix the --tx option value like this::
--tx 3*popen//python=python2.4
then three subprocesses would be created and tests
will be load-balanced across these three processes.
will be load-balanced across these three processes.
Sending tests to remote SSH accounts
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Suppose you have a package ``mypkg`` which contains some
Suppose you have a package ``mypkg`` which contains some
tests that you can successfully run locally. And you
have a ssh-reachable machine ``myhost``. Then
have a ssh-reachable machine ``myhost``. Then
you can ad-hoc distribute your tests by typing::
py.test -d --tx ssh=myhostpopen --rsyncdir mypkg mypkg
This will synchronize your ``mypkg`` package directory
to an remote ssh account and then locally collect tests
and send them to remote places for execution.
This will synchronize your ``mypkg`` package directory
to an remote ssh account and then locally collect tests
and send them to remote places for execution.
You can specify multiple ``--rsyncdir`` directories
to be sent to the remote side.
You can specify multiple ``--rsyncdir`` directories
to be sent to the remote side.
**NOTE:** For py.test to collect and send tests correctly
you not only need to make sure all code and tests
directories are rsynced, but that any test (sub) directory
also has an ``__init__.py`` file because internally
py.test references tests as a fully qualified python
module path. **You will otherwise get strange errors**
module path. **You will otherwise get strange errors**
during setup of the remote side.
Sending tests to remote Socket Servers
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Download the single-module `socketserver.py`_ Python program
Download the single-module `socketserver.py`_ Python program
and run it like this::
python socketserver.py
It will tell you that it starts listening on the default
port. You can now on your home machine specify this
port. You can now on your home machine specify this
new socket host with something like this::
py.test -d --tx socket=192.168.1.102:8888 --rsyncdir mypkg mypkg
@@ -102,17 +102,17 @@ new socket host with something like this::
.. _`atonce`:
Running tests on many platforms at once
Running tests on many platforms at once
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
The basic command to run tests on multiple platforms is::
py.test --dist=each --tx=spec1 --tx=spec2
py.test --dist=each --tx=spec1 --tx=spec2
If you specify a windows host, an OSX host and a Linux
environment this command will send each tests to all
environment this command will send each tests to all
platforms - and report back failures from all platforms
at once. The specifications strings use the `xspec syntax`_.
at once. The specifications strings use the `xspec syntax`_.
.. _`xspec syntax`: http://codespeak.net/execnet/trunk/basics.html#xspec
@@ -123,14 +123,14 @@ at once. The specifications strings use the `xspec syntax`_.
Specifying test exec environments in a conftest.py
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Instead of specifying command line options, you can
Instead of specifying command line options, you can
put options values in a ``conftest.py`` file like this::
option_tx = ['ssh=myhost//python=python2.5', 'popen//python=python2.5']
option_dist = True
Any commandline ``--tx`` specifictions will add to the list of
available execution environments.
available execution environments.
Specifying "rsync" dirs in a conftest.py
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
@@ -156,11 +156,11 @@ command line options
box each test run in a separate process (unix)
``--dist=distmode``
set mode for distributing tests to exec environments.
each: send each test to each available environment.
load: send each test to available environment.
(default) no: run tests inprocess, don't distribute.
``--tx=xspec``
add a test execution environment. some examples: --tx popen//python=python2.5 --tx socket=192.168.1.102:8888 --tx ssh=user@codespeak.net//chdir=testcache