some more improvements and updates to docs, add release announcements

This commit is contained in:
holger krekel 2010-11-06 11:38:53 +01:00
parent 6dac77433e
commit fcebf4f557
47 changed files with 315 additions and 254 deletions

22
doc/announce/index.txt Normal file
View File

@ -0,0 +1,22 @@
Release announcements
===========================================
.. toctree::
:maxdepth: 2
release-2.0.0
release-1.3.4
release-1.3.3
release-1.3.2
release-1.3.1
release-1.3.0
release-1.2.1
release-1.2.0
release-1.1.1
release-1.1.0
release-1.0.2
release-1.0.1
release-1.0.0
release-0.9.2
release-0.9.0

View File

@ -0,0 +1,50 @@
py.test 2.0.0: standalone, features++, implementation++, docs++
===========================================================================
XXX PENDING
Welcome to pytest-2.0.0! With this release py.test becomes its own standalone
PyPI distribution, named ``pytest``, installing the ``py.test`` command line
tool. Apart from a great internal cleanup this release comes with tons
of improvements and new features and a completely revamped extensive
documentation, including many continously tested examples. See
http://pytest.org
New Features
-----------------------
- new invocations through Python interpreter and from Python::
python -m pytest # on all pythons >= 2.7
python -m pytest.main # on all pythons >= 2.5
import pytest ; pytest.main(args, plugins)
see http://pytest.org/2.0.0/invoke.html for details.
- new configuration through ini-files (setup.cfg or tox.ini recognized),
for example::
[pytest]
norecursedirs = .hg _build
python_collect_funcprefix = test_
python_collect_classprefix = Test
see http://pytest.org/2.0.0/customize.html
-
Thanks to issue reporters, people asking questions, complaining and
generally to Ronny Pfannschmidt for his awesome help on many issues.
cheers,
holger krekel
Changes between 1.3.3 and 1.3.4
==================================================
- fix issue111: improve install documentation for windows
- fix issue119: fix custom collectability of __init__.py as a module
- fix issue116: --doctestmodules work with __init__.py files as well
- fix issue115: unify internal exception passthrough/catching/GeneratorExit
- fix issue118: new --tb=native for presenting cpython-standard exceptions

View File

@ -1,16 +0,0 @@
=============
Release notes
=============
Contents:
.. toctree::
:maxdepth: 2
.. include: release-1.1.0
.. include: release-1.0.2
release-1.0.1
release-1.0.0
release-0.9.2
release-0.9.0

View File

@ -20,5 +20,6 @@ py.test reference documentation
mark.txt
recwarn.txt
unittest.txt
nose.txt
doctest.txt

View File

@ -21,7 +21,7 @@ assertion fails you will see the value of ``x``::
$ py.test test_assert1.py
=========================== test session starts ============================
platform linux2 -- Python 2.6.5 -- pytest-2.0.0.dev17
platform linux2 -- Python 2.6.5 -- pytest-2.0.0.dev19
test path 1: test_assert1.py
test_assert1.py F
@ -101,7 +101,7 @@ if you run this module::
$ py.test test_assert2.py
=========================== test session starts ============================
platform linux2 -- Python 2.6.5 -- pytest-2.0.0.dev17
platform linux2 -- Python 2.6.5 -- pytest-2.0.0.dev19
test path 1: test_assert2.py
test_assert2.py F

View File

@ -28,25 +28,25 @@ You can ask for available builtin or project-custom
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
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.
tmpdir
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.
monkeypatch
The returned ``monkeypatch`` funcarg provides these
helper methods to modify objects, dictionaries or os.environ::
monkeypatch.setattr(obj, name, value, raising=True)
monkeypatch.delattr(obj, name, raising=True)
monkeypatch.setitem(mapping, name, value)
@ -54,15 +54,15 @@ You can ask for available builtin or project-custom
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.
recwarn
Return a WarningsRecorder instance that provides these methods:
* ``pop(category=None)``: return last warning matching the category.
* ``clear()``: clear list of warnings

View File

@ -25,7 +25,7 @@ import sys, os
# Add any Sphinx extension module names here, as strings. They can be extensions
# coming with Sphinx (named 'sphinx.ext.*') or your custom ones.
extensions = ['sphinx.ext.autodoc', 'sphinx.ext.todo',
extensions = ['sphinx.ext.autodoc', 'sphinx.ext.todo', 'sphinx.ext.autosummary',
'sphinx.ext.intersphinx', 'sphinx.ext.viewcode']
# Add any paths that contain templates here, relative to this directory.
@ -65,7 +65,7 @@ release = '2.0.0dev0'
# List of patterns, relative to source directory, that match files and
# directories to ignore when looking for source files.
exclude_patterns = ['links.inc', '_build', 'test', 'announce'] # XXX
exclude_patterns = ['links.inc', '_build', 'test', ] # XXX
# The reST default role (used for this markup: `text`) to use for all documents.
#default_role = None

View File

@ -1,11 +1,13 @@
.. _`contact channels`:
.. _`contact`:
Contact channels
===================================
- `new issue tracker`_ to report bugs or suggest features.
See also the `old issue tracker`_ but don't submit bugs there.
- `new issue tracker`_ to report bugs or suggest features (for version
2.0 and above). You may also peek at the `old issue tracker`_ but please
don't submit bugs there anymore.
- `Testing In Python`_: a mailing list for Python testing tools and discussion.

View File

@ -44,7 +44,7 @@ then you can just invoke ``py.test`` without command line options::
$ py.test
=========================== test session starts ============================
platform linux2 -- Python 2.6.5 -- pytest-2.0.0.dev17
test path 1: /tmp/doc-exec-197
platform linux2 -- Python 2.6.5 -- pytest-2.0.0.dev19
test path 1: /tmp/doc-exec-400
============================= in 0.00 seconds =============================

View File

@ -3,8 +3,9 @@ writing well integrated assertion helpers
========================================================
If you have a test helper function called from a test you can
use the ``pytest.fail``_ builtin to cleanly fail a test with a message.
The test support function will never itself show up in the traceback.
use the ``pytest.fail`` marker to fail a test with a certain message.
The test support function will not show up in the traceback if you
set the ``__tracebackhide__`` option somewhere in the helper function.
Example::
# content of test_checkconfig.py
@ -33,4 +34,3 @@ Let's run our little function::
test_checkconfig.py:8: Failed
1 failed in 0.02 seconds

View File

@ -36,12 +36,12 @@ and when running it will see a skipped "slow" test::
$ py.test test_module.py -rs # "-rs" means report on the little 's'
=========================== test session starts ============================
platform linux2 -- Python 2.6.5 -- pytest-2.0.0.dev17
platform linux2 -- Python 2.6.5 -- pytest-2.0.0.dev19
test path 1: test_module.py
test_module.py .s
========================= short test summary info ==========================
SKIP [1] /tmp/doc-exec-195/conftest.py:9: 'need --runslow option to run'
SKIP [1] /tmp/doc-exec-435/conftest.py:9: need --runslow option to run
=================== 1 passed, 1 skipped in 0.02 seconds ====================
@ -49,7 +49,7 @@ Or run it including the ``slow`` marked test::
$ py.test test_module.py --runslow
=========================== test session starts ============================
platform linux2 -- Python 2.6.5 -- pytest-2.0.0.dev17
platform linux2 -- Python 2.6.5 -- pytest-2.0.0.dev19
test path 1: test_module.py
test_module.py ..

View File

@ -4,6 +4,9 @@
Usages and Examples
===========================================
This is a (growing) list of examples. :ref:`Contact <contact>` us if you
need more examples or have questions.
.. toctree::
:maxdepth: 2
@ -14,3 +17,4 @@ Usages and Examples
detectpytest.txt
nonpython.txt
simple.txt
xunit_setup.txt

View File

@ -49,7 +49,7 @@ You can now run the test::
$ py.test test_sample.py
=========================== test session starts ============================
platform linux2 -- Python 2.6.5 -- pytest-2.0.0.dev17
platform linux2 -- Python 2.6.5 -- pytest-2.0.0.dev19
test path 1: test_sample.py
test_sample.py F
@ -57,7 +57,7 @@ You can now run the test::
================================= FAILURES =================================
_______________________________ test_answer ________________________________
mysetup = <conftest.MySetup instance at 0x2809a70>
mysetup = <conftest.MySetup instance at 0x1cf6b90>
def test_answer(mysetup):
app = mysetup.myapp()
@ -122,12 +122,12 @@ Running it yields::
$ py.test test_ssh.py -rs
=========================== test session starts ============================
platform linux2 -- Python 2.6.5 -- pytest-2.0.0.dev17
platform linux2 -- Python 2.6.5 -- pytest-2.0.0.dev19
test path 1: test_ssh.py
test_ssh.py s
========================= short test summary info ==========================
SKIP [1] /tmp/doc-exec-198/conftest.py:22: 'specify ssh host with --ssh'
SKIP [1] /tmp/doc-exec-438/conftest.py:22: specify ssh host with --ssh
======================== 1 skipped in 0.02 seconds =========================

View File

@ -27,17 +27,17 @@ now execute the test specification::
nonpython $ py.test test_simple.yml
=========================== test session starts ============================
platform linux2 -- Python 2.6.5 -- pytest-2.0.0.dev17
platform linux2 -- Python 2.6.5 -- pytest-2.0.0.dev19
test path 1: test_simple.yml
test_simple.yml .F
================================= FAILURES =================================
______________________________ usecase: hello ______________________________
usecase execution failed
spec failed: 'some': 'other'
no further details known at this point.
==================== 1 failed, 1 passed in 0.37 seconds ====================
==================== 1 failed, 1 passed in 0.42 seconds ====================
You get one dot for the passing ``sub1: sub1`` check and one failure.
Obviously in the above ``conftest.py`` you'll want to implement a more
@ -47,22 +47,21 @@ your own domain specific testing language this way.
.. note::
``repr_failure(excinfo)`` is called for representing test failures.
If you create custom collection nodes you can return an error
If you create custom collection nodes you can return an error
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
``reportinfo()`` is used for representing the test location and is also consulted for
reporting in ``verbose`` mode::
nonpython $ py.test -v
=========================== test session starts ============================
platform linux2 -- Python 2.6.5 -- pytest-2.0.0.dev17 -- /home/hpk/venv/0/bin/python
platform linux2 -- Python 2.6.5 -- pytest-2.0.0.dev19 -- /home/hpk/venv/0/bin/python
test path 1: /home/hpk/p/pytest/doc/example/nonpython
test_simple.yml:1: usecase: ok PASSED
test_simple.yml:1: usecase: hello FAILED
test_simple.yml <- test_simple.yml:1: usecase: ok PASSED
test_simple.yml <- test_simple.yml:1: usecase: hello FAILED
================================= FAILURES =================================
______________________________ usecase: hello ______________________________
usecase execution failed
@ -74,7 +73,7 @@ While developing your custom test collection and execution it's also
interesting to just look at the collection tree::
nonpython $ py.test --collectonly
<Directory 'nonpython'>
<YamlFile 'test_simple.yml'>
<UsecaseItem 'ok'>
<UsecaseItem 'hello'>
<Collection 'nonpython'>
<YamlFile 'test_simple.yml'>
<YamlItem 'ok'>
<YamlItem 'hello'>

View File

@ -18,12 +18,11 @@ finding out what is collected
You can always peek at the collection tree without running tests like this::
$ py.test --collectonly collectonly.py
<Directory 'example'>
<Module 'test_collectonly.py'>
<Function 'test_function'>
<Class 'TestClass'>
<Instance '()'>
<Function 'test_method'>
<Function 'test_anothermethod'>
. $ py.test --collectonly collectonly.py
<Collection 'example'>
<Module 'collectonly.py'>
<Function 'test_function'>
<Class 'TestClass'>
<Instance '()'>
<Function 'test_method'>
<Function 'test_anothermethod'>

View File

@ -36,9 +36,9 @@ Let's run this without supplying our new command line option::
F
================================= FAILURES =================================
_______________________________ test_answer ________________________________
cmdopt = 'type1'
def test_answer(cmdopt):
if cmdopt == "type1":
print ("first")
@ -46,7 +46,7 @@ Let's run this without supplying our new command line option::
print ("second")
> assert 0 # to see what was printed
E assert 0
test_sample.py:6: AssertionError
----------------------------- Captured stdout ------------------------------
first
@ -58,9 +58,9 @@ And now with supplying a command line option::
F
================================= FAILURES =================================
_______________________________ test_answer ________________________________
cmdopt = 'type2'
def test_answer(cmdopt):
if cmdopt == "type1":
print ("first")
@ -68,7 +68,7 @@ And now with supplying a command line option::
print ("second")
> assert 0 # to see what was printed
E assert 0
test_sample.py:6: AssertionError
----------------------------- Captured stdout ------------------------------
second
@ -122,16 +122,15 @@ let's run the full monty::
....F
================================= FAILURES =================================
_____________________________ test_compute[4] ______________________________
param1 = 4
def test_compute(param1):
> assert param1 < 4
E assert 4 < 4
test_compute.py:3: AssertionError
1 failed, 4 passed in 0.03 seconds
1 failed, 4 passed in 0.02 seconds
As expected when running the full range of ``param1`` values
we'll get an error on the last one.

View File

@ -19,8 +19,8 @@ custom options::
.. _optparse: http://docs.python.org/library/optparse.html
Working Examples
================
order of setup/teardown module/class/item methods
====================================================
managing state at module, class and method level
------------------------------------------------------------

View File

@ -34,20 +34,20 @@ Running the test looks like this::
$ py.test test_simplefactory.py
=========================== test session starts ============================
platform linux2 -- Python 2.6.5 -- pytest-2.0.0.dev17
platform linux2 -- Python 2.6.5 -- pytest-2.0.0.dev19
test path 1: test_simplefactory.py
test_simplefactory.py F
================================= FAILURES =================================
______________________________ test_function _______________________________
myfuncarg = 42
def test_function(myfuncarg):
> assert myfuncarg == 17
E assert 42 == 17
test_simplefactory.py:5: AssertionError
========================= 1 failed in 0.02 seconds =========================
@ -136,70 +136,52 @@ Running this::
$ py.test test_example.py
=========================== test session starts ============================
platform linux2 -- Python 2.6.5 -- pytest-2.0.0.dev17
platform linux2 -- Python 2.6.5 -- pytest-2.0.0.dev19
test path 1: test_example.py
test_example.py .........F
================================= FAILURES =================================
_______________________________ test_func[9] _______________________________
numiter = 9
def test_func(numiter):
> assert numiter < 9
E assert 9 < 9
test_example.py:7: AssertionError
==================== 1 failed, 9 passed in 0.03 seconds ====================
==================== 1 failed, 9 passed in 0.04 seconds ====================
Note that the ``pytest_generate_tests(metafunc)`` hook is called during
the test collection phase which is separate from the actual test running.
Let's just look at what is collected::
$ py.test --collectonly test_example.py
<Directory 'doc-exec-167'>
<Module 'test_example.py'>
<Function 'test_func[0]'>
<Function 'test_func[1]'>
<Function 'test_func[2]'>
<Function 'test_func[3]'>
<Function 'test_func[4]'>
<Function 'test_func[5]'>
<Function 'test_func[6]'>
<Function 'test_func[7]'>
<Function 'test_func[8]'>
<Function 'test_func[9]'>
<Collection 'doc-exec-403'>
<Module 'test_example.py'>
<Function 'test_func[0]'>
<Function 'test_func[1]'>
<Function 'test_func[2]'>
<Function 'test_func[3]'>
<Function 'test_func[4]'>
<Function 'test_func[5]'>
<Function 'test_func[6]'>
<Function 'test_func[7]'>
<Function 'test_func[8]'>
<Function 'test_func[9]'>
If you want to select only the run with the value ``7`` you could do::
$ py.test -v -k 7 test_example.py # or -k test_func[7]
=========================== test session starts ============================
platform linux2 -- Python 2.6.5 -- pytest-2.0.0.dev17 -- /home/hpk/venv/0/bin/python
platform linux2 -- Python 2.6.5 -- pytest-2.0.0.dev19 -- /home/hpk/venv/0/bin/python
test path 1: test_example.py
test_example.py:6: test_func[0] PASSED
test_example.py:6: test_func[1] PASSED
test_example.py:6: test_func[2] PASSED
test_example.py:6: test_func[3] PASSED
test_example.py:6: test_func[4] PASSED
test_example.py:6: test_func[5] PASSED
test_example.py:6: test_func[6] PASSED
test_example.py:6: test_func[7] PASSED
test_example.py:6: test_func[8] PASSED
test_example.py:6: test_func[9] FAILED
================================= FAILURES =================================
_______________________________ test_func[9] _______________________________
numiter = 9
def test_func(numiter):
> assert numiter < 9
E assert 9 < 9
test_example.py:7: AssertionError
==================== 1 failed, 9 passed in 0.04 seconds ====================
test_example.py <- test_example.py:6: test_func[7] PASSED
======================== 9 tests deselected by '7' =========================
================== 1 passed, 9 deselected in 0.01 seconds ==================
.. _`metafunc object`:

View File

@ -14,6 +14,7 @@ Installation options::
To check your installation has installed the correct version::
$ py.test --version
This is py.test version 2.0.0.dev19, imported from /home/hpk/p/pytest/pytest
If you get an error checkout :ref:`installation issues`.
@ -33,8 +34,8 @@ That's it. You can execute the test function now::
$ py.test
=========================== test session starts ============================
platform linux2 -- Python 2.6.5 -- pytest-2.0.0.dev18
test path 1: /tmp/doc-exec-211
platform linux2 -- Python 2.6.5 -- pytest-2.0.0.dev19
test path 1: /tmp/doc-exec-404
test_sample.py F
@ -120,7 +121,7 @@ run the module by passing its filename::
================================= FAILURES =================================
____________________________ TestClass.test_two ____________________________
self = <test_class.TestClass instance at 0x19c6638>
self = <test_class.TestClass instance at 0x2c2c560>
def test_two(self):
x = "hello"
@ -156,7 +157,7 @@ before performing the test function call. Let's just run it::
================================= FAILURES =================================
_____________________________ test_needsfiles ______________________________
tmpdir = local('/tmp/pytest-1306/test_needsfiles0')
tmpdir = local('/tmp/pytest-240/test_needsfiles0')
def test_needsfiles(tmpdir):
print tmpdir
@ -165,7 +166,7 @@ before performing the test function call. Let's just run it::
test_tmpdir.py:3: AssertionError
----------------------------- Captured stdout ------------------------------
/tmp/pytest-1306/test_needsfiles0
/tmp/pytest-240/test_needsfiles0
1 failed in 0.04 seconds
Before the test runs, a unique-per-test-invocation temporary directory

View File

@ -19,6 +19,7 @@ Welcome to ``py.test`` documentation:
example/index
talks
develop
announce/index
.. toctree::
:hidden:

View File

@ -88,8 +88,8 @@ You can use the ``-k`` command line option to select tests::
$ py.test -k webtest # running with the above defined examples yields
=========================== test session starts ============================
platform linux2 -- Python 2.6.5 -- pytest-2.0.0.dev17
test path 1: /tmp/doc-exec-171
platform linux2 -- Python 2.6.5 -- pytest-2.0.0.dev19
test path 1: /tmp/doc-exec-407
test_mark.py ..
test_mark_classlevel.py ..
@ -100,8 +100,8 @@ And you can also run all tests except the ones that match the keyword::
$ py.test -k-webtest
=========================== test session starts ============================
platform linux2 -- Python 2.6.5 -- pytest-2.0.0.dev17
test path 1: /tmp/doc-exec-171
platform linux2 -- Python 2.6.5 -- pytest-2.0.0.dev19
test path 1: /tmp/doc-exec-407
===================== 4 tests deselected by '-webtest' =====================
======================= 4 deselected in 0.01 seconds =======================
@ -110,8 +110,8 @@ Or to only select the class::
$ py.test -kTestClass
=========================== test session starts ============================
platform linux2 -- Python 2.6.5 -- pytest-2.0.0.dev17
test path 1: /tmp/doc-exec-171
platform linux2 -- Python 2.6.5 -- pytest-2.0.0.dev19
test path 1: /tmp/doc-exec-407
test_mark_classlevel.py ..

View File

@ -39,8 +39,8 @@ will be undone.
.. background check:
$ py.test
=========================== test session starts ============================
platform linux2 -- Python 2.6.5 -- pytest-2.0.0.dev17
test path 1: /tmp/doc-exec-172
platform linux2 -- Python 2.6.5 -- pytest-2.0.0.dev19
test path 1: /tmp/doc-exec-408
============================= in 0.00 seconds =============================

42
doc/nose.txt Normal file
View File

@ -0,0 +1,42 @@
Running test written for nose
=======================================
.. include:: links.inc
py.test has basic support for running tests written for nose_.
This is implemented in :pymod:`pytest.plugin.nose`.
Usage
-------------
type::
py.test # instead of 'nosetests'
and you should be able to run your nose style tests and at the same
make full use of py.test's capabilities.
Supported nose Idioms
----------------------
* setup and teardown at module/class/method level
* SkipTest exceptions and markers
* setup/teardown decorators
* 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.
- no nose-configuration is recognized
If you find other issues or have suggestions please run::
py.test --pastebin=all
and send the resulting URL to a py.test contact channel,
at best to the mailing list.
"""

View File

@ -5,7 +5,7 @@ Writing, managing and understanding plugins
py.test implements all aspects of configuration, collection, running and reporting by calling `well specified hooks`_. Virtually any Python module can be registered as a plugin. It can implement any number of hook functions (usually two or three) which all have a ``pytest_`` prefix, making hook functions easy to distinguish and find. There are three basic locations types:
* builtin plugins: loaded from py.test's own `pytest/plugin`_ directory.
* `builtin plugins`_: loaded from py.test's own ``pytest/plugin`` directory.
* `external plugins`_: modules discovered through `setuptools entry points`_
* `conftest.py plugins`_: modules auto-discovered in test directories
@ -48,8 +48,8 @@ earlier than further away ones.
python package directory (i.e. one containing an ``__init__.py``) then
"import conftest" can be ambigous because there might be other
``conftest.py`` files as well on your PYTHONPATH or ``sys.path``.
It is thus good practise for projects to either put ``conftest.py``
under a package scope or to never import anything from a
It is thus good practise for projects to either put ``conftest.py``
under a package scope or to never import anything from a
conftest.py file.
.. _`installing plugins`:
@ -90,6 +90,7 @@ to implement their wide-ranging functionality.
.. _`setuptools entry points`:
Making your plugin installable by others
-----------------------------------------------
@ -97,8 +98,8 @@ If you want to make your plugin externally available, you
may define a so called entry point for your distribution so
that ``py.test`` finds your plugin module. Entry points are
a feature that is provided by `setuptools`_ or `Distribute`_.
The concrete entry point is ``pytest11``. To make your plugin
available you can insert the following lines in your
The concrete entry point is ``pytest11``. To make your plugin
available you can insert the following lines in your
setuptools/distribute-based setup-invocation:
.. sourcecode:: python
@ -171,6 +172,37 @@ the plugin manager like this:
If you want to look at the names of existing plugins, use
the ``--traceconfig`` option.
.. _`builtin plugins`:
py.test default plugin reference
====================================
.. autosummary::
pytest.plugin.assertion
pytest.plugin.capture
pytest.plugin.config
pytest.plugin.doctest
pytest.plugin.genscript
pytest.plugin.helpconfig
pytest.plugin.junitxml
pytest.plugin.mark
pytest.plugin.monkeypatch
pytest.plugin.nose
pytest.plugin.pastebin
pytest.plugin.pdb
pytest.plugin.pytester
pytest.plugin.python
pytest.plugin.recwarn
pytest.plugin.resultlog
pytest.plugin.runner
pytest.plugin.session
pytest.plugin.skipping
pytest.plugin.terminal
pytest.plugin.tmpdir
pytest.plugin.unittest
.. _`well specified hooks`:
py.test hook reference
@ -183,7 +215,7 @@ py.test calls hook functions to implement initialization, running,
test execution and reporting. When py.test loads a plugin it validates
that all hook functions conform to their respective hook specification.
Each hook function name and its argument names need to match a hook
specification exactly but it is allowed for a hook function to accept
specification exactly but it is allowed for a hook function to accept
*less* parameters than specified. If you mistype argument names or the
hook name itself you get useful errors.
@ -261,7 +293,7 @@ Reference of important objects involved in hooks
.. autoclass:: pytest.plugin.session.Node(name, parent)
:members:
..
..
.. autoclass:: pytest.plugin.session.File(fspath, parent)
:members:

View File

@ -20,15 +20,15 @@ and more. Here is an example test usage::
p = tmpdir.mkdir("sub").join("hello.txt")
p.write("content")
assert p.read() == "content"
assert tmpdir.listdir() == 1
assert len(tmpdir.listdir()) == 1
assert 0
Running this would result in a passed test except for the last
Running this would result in a passed test except for the last
``assert 0`` line which we use to look at values::
$ py.test test_tmpdir.py
=========================== test session starts ============================
platform linux2 -- Python 2.6.5 -- pytest-2.0.0.dev17
platform linux2 -- Python 2.6.5 -- pytest-2.0.0.dev19
test path 1: test_tmpdir.py
test_tmpdir.py F
@ -36,13 +36,15 @@ Running this would result in a passed test except for the last
================================= FAILURES =================================
_____________________________ test_create_file _____________________________
tmpdir = local('/tmp/pytest-1248/test_create_file0')
tmpdir = local('/tmp/pytest-243/test_create_file0')
def test_create_file(tmpdir):
p = tmpdir.mkdir("sub").join("hello.txt")
p.write("content")
assert p.read() == "content"
assert len(os.listdir(str(tmpdir))) == 1
assert len(tmpdir.listdir()) == 1
> assert 0
E assert 0
test_tmpdir.py:7: AssertionError
========================= 1 failed in 0.04 seconds =========================
@ -52,7 +54,7 @@ Running this would result in a passed test except for the last
the default base temporary directory
-----------------------------------------------
..
..
You can create directories by calling one of two methods
on the config object:
- ``config.mktemp(basename)``: create and return a new tempdir
@ -61,14 +63,14 @@ the default base temporary directory
Temporary directories are by default created as sub directories of
the system temporary directory. The name will be ``pytest-NUM`` where
``NUM`` will be incremenated with each test run. Moreover, entries older
than 3 temporary directories will be removed.
than 3 temporary directories will be removed.
You can override the default temporary directory logic and set it like this::
py.test --basetemp=mydir
When distributing tests on the local machine, ``py.test`` takes care to
configure a basetemp directory for the sub processes such that all
When distributing tests on the local machine, ``py.test`` takes care to
configure a basetemp directory for the sub processes such that all
temporary data lands below below a single per-test run basetemp directory.
.. _`py.path.local`: http://pylib.org/path.html

View File

@ -24,7 +24,7 @@ Running it yields::
$ py.test test_unittest.py
=========================== test session starts ============================
platform linux2 -- Python 2.6.5 -- pytest-2.0.0.dev17
platform linux2 -- Python 2.6.5 -- pytest-2.0.0.dev19
test path 1: test_unittest.py
test_unittest.py F
@ -32,7 +32,7 @@ Running it yields::
================================= FAILURES =================================
____________________________ MyTest.test_method ____________________________
self = <test_unittest.MyTest testMethod=run>
self = <test_unittest.MyTest testMethod=test_method>
def test_method(self):
x = 1
@ -41,7 +41,7 @@ Running it yields::
test_unittest.py:8:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
self = <test_unittest.MyTest testMethod=run>, first = 1, second = 3
self = <test_unittest.MyTest testMethod=test_method>, first = 1, second = 3
msg = None
def failUnlessEqual(self, first, second, msg=None):

View File

@ -1,3 +1,6 @@
"""
support for presented detailed information in failing assertions.
"""
import py
import sys

View File

@ -1,6 +1,4 @@
""" plugin for configurable per-test stdout/stderr capturing mechanisms and
``capsys`` and ``capfd`` function arguments.
"""
""" per-test stdout/stderr capturing mechanisms, ``capsys`` and ``capfd`` function arguments. """
import py
import os

View File

@ -1,10 +1,10 @@
""" command line configuration, ini-file and conftest.py processing. """
import py
import sys, os
from pytest.main import PluginManager
import pytest
def pytest_cmdline_parse(pluginmanager, args):
config = Config(pluginmanager)
config.parse(args)

View File

@ -1,4 +1,4 @@
""" collect and execute doctests from modules and test files."""
""" discover and run doctests in modules and test files."""
import py
from py._code.code import TerminalRepr, ReprFileLocation

View File

@ -1,3 +1,4 @@
""" generate a single-file self-contained version of py.test """
import py
import pickle
import zlib

View File

@ -1,5 +1,4 @@
""" provide version info, conftest/environment config names.
"""
""" version info, help messages, tracing configuration. """
import py
import pytest
import inspect, sys

View File

@ -1,5 +1,6 @@
""" logging of test results in JUnit-XML format, for use with Hudson
and build integration servers. Based on initial code from Ross Lawley.
""" report test results in JUnit-XML format, for use with Hudson and build integration servers.
Based on initial code from Ross Lawley.
"""
import py

View File

@ -70,7 +70,7 @@ def matchonekeyword(key, itemkeywords):
return True
class MarkGenerator:
""" Factory for :class:`MarkDecorator` objects - exposed as
""" Factory for :class:`MarkDecorator` objects - exposed as
a ``py.test.mark`` singleton instance. Example::
import py
@ -88,8 +88,8 @@ class MarkGenerator:
class MarkDecorator:
""" A decorator for test functions and test classes. When applied
it will create :class:`MarkInfo` objects which may be
:ref:`retrieved by hooks as item keywords` MarkDecorator instances
it will create :class:`MarkInfo` objects which may be
:ref:`retrieved by hooks as item keywords` MarkDecorator instances
are usually created by writing::
mark1 = py.test.mark.NAME # simple MarkDecorator

View File

@ -66,7 +66,7 @@ class monkeypatch:
def setenv(self, name, value, prepend=None):
""" set environment variable ``name`` to ``value``. if ``prepend``
is a character, read the current environment variable value
is a character, read the current environment variable value
and prepend the ``value`` adjoined with the ``prepend`` character."""
value = str(value)
if prepend and name in os.environ:

View File

@ -1,42 +1,5 @@
"""nose-compatibility plugin: allow to run nose test suites natively.
"""run test suites written for nose. """
This is an experimental plugin for allowing to run tests written
in 'nosetests style with py.test.
Usage
-------------
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.
Supported nose Idioms
----------------------
* setup and teardown at module/class/method level
* SkipTest exceptions and markers
* setup/teardown decorators
* 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.
- no nose-configuration is recognized
If you find other issues or have suggestions please run::
py.test --pastebin=all
and send the resulting URL to a py.test contact channel,
at best to the mailing list.
"""
import py
import inspect
import sys

View File

@ -1,6 +1,5 @@
"""
interactive debugging with the Python Debugger.
"""
""" interactive debugging with PDB, the Python Debugger. """
import py
import sys

View File

@ -1,6 +1,4 @@
"""
funcargs and support code for testing py.test's own functionality.
"""
""" (disabled by default) support for testing py.test and py.test plugins. """
import py, pytest
import sys, os

View File

@ -1,6 +1,4 @@
"""
Python related collection nodes.
"""
""" Python test discovery, setup and run of test functions. """
import py
import inspect
import sys

View File

@ -1,4 +1,4 @@
""" record warnings to allow assertions about them. """
""" recording warnings during test function execution. """
import py
import sys, os

View File

@ -1,4 +1,4 @@
""" create machine readable plain text file with results. """
""" (disabled by default) create result information in a plain text file. """
import py
from py.builtin import print_

View File

@ -1,6 +1,4 @@
"""
collect and run test items and create reports.
"""
""" basic collect and runtest protocol implementations """
import py, sys
from py._code.code import TerminalRepr
@ -92,11 +90,12 @@ def call_runtest_hook(item, when):
return CallInfo(lambda: ihook(item=item), when=when)
class CallInfo:
""" Call Information about a hook call. """
""" Result/Exception info a function invocation. """
#: None or ExceptionInfo object.
excinfo = None
def __init__(self, func, when):
#: one of "setup", "call", "teardown" specifying the runtest phase.
#: context of invocation: one of "setup", "call",
#: "teardown", "memocollect"
self.when = when
try:
self.result = func()

View File

@ -1,8 +1,4 @@
""" basic test session implementation.
* drives collection of tests
* triggers executions of tests
"""
""" core implementation of testing process: init, collection, runtest loop. """
import py
import pytest
@ -174,10 +170,10 @@ class Node(object):
#: the test config object
self.config = config or parent.config
#: the collection this node is part of.
#: the collection this node is part of
self.collection = collection or parent.collection
#: the file where this item is contained/collected from.
#: filesystem path where this node was collected from
self.fspath = getattr(parent, 'fspath', None)
self.ihook = self.collection.gethookproxy(self.fspath)
self.keywords = {self.name: True}

View File

@ -1,6 +1,4 @@
"""
plugin providing skip and xfail functionality.
"""
""" support for skip/xfail functions and markers. """
import py, pytest

View File

@ -1,5 +1,4 @@
"""
Implements terminal reporting of the full testing process.
""" terminal reporting of the full testing process.
This is a good source for looking at the various reporting hooks.
"""

View File

@ -1,13 +1,4 @@
"""provide temporary directories to test functions.
usage example::
def test_plugin(tmpdir):
tmpdir.join("hello").write("hello")
.. _`py.path.local`: ../../path.html
"""
""" support for providing temporary directories to test functions. """
import pytest, py
def pytest_configure(config):

View File

@ -1,6 +1,4 @@
"""
automatically discover and run traditional "unittest.py" style tests.
"""
""" support discovery and running of traditional "unittest.py" style tests. """
import py
import sys