some more improvements and updates to docs, add release announcements
This commit is contained in:
holger krekel
@@ -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
|
||||
@@ -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
|
||||
@@ -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
|
||||
@@ -20,5 +20,6 @@ py.test reference documentation
|
||||
mark.txt
|
||||
recwarn.txt
|
||||
unittest.txt
|
||||
nose.txt
|
||||
doctest.txt
|
||||
|
||||
|
||||
+2
-2
@@ -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
|
||||
|
||||
+8
-8
@@ -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
|
||||
|
||||
|
||||
|
||||
+2
-2
@@ -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
|
||||
|
||||
+4
-2
@@ -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.
|
||||
|
||||
|
||||
+2
-2
@@ -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 =============================
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
@@ -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 ..
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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 =========================
|
||||
|
||||
|
||||
+15
-16
@@ -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'>
|
||||
|
||||
@@ -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'>
|
||||
|
||||
+10
-11
@@ -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.
|
||||
|
||||
@@ -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
|
||||
------------------------------------------------------------
|
||||
|
||||
+31
-49
@@ -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`:
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -19,6 +19,7 @@ Welcome to ``py.test`` documentation:
|
||||
example/index
|
||||
talks
|
||||
develop
|
||||
announce/index
|
||||
|
||||
.. toctree::
|
||||
:hidden:
|
||||
|
||||
+6
-6
@@ -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 ..
|
||||
|
||||
|
||||
+2
-2
@@ -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 =============================
|
||||
|
||||
|
||||
@@ -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.
|
||||
"""
|
||||
+39
-7
@@ -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:
|
||||
|
||||
|
||||
+12
-10
@@ -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
|
||||
|
||||
+3
-3
@@ -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):
|
||||
|
||||
Reference in New Issue
Block a user