p53209761
/
test_ok2
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Introduce pytest command as recommended entry point 

Fixes #1629
This commit is contained in:
Dave Hunt 2016-06-21 16:16:57 +02:00
parent 54872e94b4
commit ef9dd14963
55 changed files with 272 additions and 274 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
.github/ISSUE_TEMPLATE.md vendored
View File

@ -4,5 +4,5 @@ Here's a quick checklist in what to include:
- [ ] Include a detailed description of the bug or suggestion
- [ ] `pip list` of the virtual environment you are using
- [ ] py.test and operating system versions
- [ ] pytest and operating system versions
- [ ] Minimal example if possible

4
README.rst
View File

@ -33,7 +33,7 @@ An example of a simple test:
To execute it::
$ py.test
$ pytest
======= test session starts ========
platform linux -- Python 3.4.3, pytest-2.8.5, py-1.4.31, pluggy-0.3.1
collected 1 items
@ -51,7 +51,7 @@ To execute it::
test_sample.py:5: AssertionError
======= 1 failed in 0.12 seconds ========
Due to ``py.test``'s detailed assertion introspection, only plain ``assert`` statements are used. See `getting-started <http://pytest.org/latest/getting-started.html#our-first-test-run>`_ for more examples.
Due to ``pytest``'s detailed assertion introspection, only plain ``assert`` statements are used. See `getting-started <http://pytest.org/latest/getting-started.html#our-first-test-run>`_ for more examples.
Features

2
_pytest/capture.py
View File

@ -463,7 +463,7 @@ def _readline_workaround():
Pdb uses readline support where available--when not running from the Python
prompt, the readline module is not imported until running the pdb REPL. If
running py.test with the --pdb option this means the readline module is not
running pytest with the --pdb option this means the readline module is not
imported until after I/O capture has been started.
This is a problem for pyreadline, which is often used to implement readline

2
_pytest/genscript.py
View File

@ -99,7 +99,7 @@ def pytest_namespace():
def freeze_includes():
"""
Returns a list of module names used by py.test that should be
Returns a list of module names used by pytest that should be
included by cx_freeze.
"""
result = list(_iter_all_modules(py))

4
_pytest/helpconfig.py
View File

@ -92,8 +92,8 @@ def showhelp(config):
tw.line()
tw.line()
tw.line("to see available markers type: py.test --markers")
tw.line("to see available fixtures type: py.test --fixtures")
tw.line("to see available markers type: pytest --markers")
tw.line("to see available fixtures type: pytest --fixtures")
tw.line("(shown according to specified file_or_dir or current dir "
"if not specified)")

2
_pytest/hookspec.py
View File

@ -34,7 +34,7 @@ def pytest_addoption(parser):
.. note::
This function should be implemented only in plugins or ``conftest.py``
files situated at the tests root directory due to how py.test
files situated at the tests root directory due to how pytest
:ref:`discovers plugins during startup <pluginorder>`.
:arg parser: To add command line options, call

30
_pytest/pytester.py
View File

@ -374,10 +374,10 @@ class RunResult:
class Testdir:
"""Temporary test directory with tools to test/run py.test itself.
"""Temporary test directory with tools to test/run pytest itself.
This is based on the ``tmpdir`` fixture but provides a number of
methods which aid with testing py.test itself. Unless
methods which aid with testing pytest itself. Unless
:py:meth:`chdir` is used all methods will use :py:attr:`tmpdir` as
current working directory.
@ -588,7 +588,7 @@ class Testdir:
"""Return the collection node of a file.
This is like :py:meth:`getnode` but uses
:py:meth:`parseconfigure` to create the (configured) py.test
:py:meth:`parseconfigure` to create the (configured) pytest
Config instance.
:param path: A :py:class:`py.path.local` instance of the file.
@ -656,7 +656,7 @@ class Testdir:
:py:class:`HookRecorder` instance.
This runs the :py:func:`pytest.main` function to run all of
py.test inside the test process itself like
pytest inside the test process itself like
:py:meth:`inline_run`. However the return value is a tuple of
the collection items and a :py:class:`HookRecorder` instance.
@ -669,7 +669,7 @@ class Testdir:
"""Run ``pytest.main()`` in-process, returning a HookRecorder.
This runs the :py:func:`pytest.main` function to run all of
py.test inside the test process itself. This means it can
pytest inside the test process itself. This means it can
return a :py:class:`HookRecorder` instance which gives more
detailed results from then run then can be done by matching
stdout/stderr from :py:meth:`runpytest`.
@ -755,9 +755,9 @@ class Testdir:
return args
def parseconfig(self, *args):
"""Return a new py.test Config instance from given commandline args.
"""Return a new pytest Config instance from given commandline args.
This invokes the py.test bootstrapping code in _pytest.config
This invokes the pytest bootstrapping code in _pytest.config
to create a new :py:class:`_pytest.core.PluginManager` and
call the pytest_cmdline_parse hook to create new
:py:class:`_pytest.config.Config` instance.
@ -777,7 +777,7 @@ class Testdir:
return config
def parseconfigure(self, *args):
"""Return a new py.test configured Config instance.
"""Return a new pytest configured Config instance.
This returns a new :py:class:`_pytest.config.Config` instance
like :py:meth:`parseconfig`, but also calls the
@ -792,7 +792,7 @@ class Testdir:
def getitem(self, source, funcname="test_func"):
"""Return the test item for a test function.
This writes the source to a python file and runs py.test's
This writes the source to a python file and runs pytest's
collection on the resulting module, returning the test item
for the requested function name.
@ -812,7 +812,7 @@ class Testdir:
def getitems(self, source):
"""Return all test items collected from the module.
This writes the source to a python file and runs py.test's
This writes the source to a python file and runs pytest's
collection on the resulting module, returning all test items
contained within.
@ -824,7 +824,7 @@ class Testdir:
"""Return the module collection node for ``source``.
This writes ``source`` to a file using :py:meth:`makepyfile`
and then runs the py.test collection on it, returning the
and then runs the pytest collection on it, returning the
collection node for the test module.
:param source: The source code of the module to collect.
@ -924,7 +924,7 @@ class Testdir:
def _getpytestargs(self):
# we cannot use "(sys.executable,script)"
# because on windows the script is e.g. a py.test.exe
# because on windows the script is e.g. a pytest.exe
return (sys.executable, _pytest_fullpath,) # noqa
def runpython(self, script):
@ -939,7 +939,7 @@ class Testdir:
return self.run(sys.executable, "-c", command)
def runpytest_subprocess(self, *args, **kwargs):
"""Run py.test as a subprocess with given arguments.
"""Run pytest as a subprocess with given arguments.
Any plugins added to the :py:attr:`plugins` list will added
using the ``-p`` command line option. Addtionally
@ -967,9 +967,9 @@ class Testdir:
return self.run(*args)
def spawn_pytest(self, string, expect_timeout=10.0):
"""Run py.test using pexpect.
"""Run pytest using pexpect.
This makes sure to use the right py.test and sets up the
This makes sure to use the right pytest and sets up the
temporary directory locations.
The pexpect child is returned.

2
_pytest/python.py
View File

@ -2173,7 +2173,7 @@ class FixtureLookupError(LookupError):
available.append(name)
msg = "fixture %r not found" % (self.argname,)
msg += "\n available fixtures: %s" %(", ".join(available),)
msg += "\n use 'py.test --fixtures [testpath]' for help on them."
msg += "\n use 'pytest --fixtures [testpath]' for help on them."
return FixtureLookupErrorRepr(fspath, lineno, tblines, msg, self.argname)

2
_pytest/standalonetemplate.py
View File

@ -17,7 +17,7 @@
#
# If you're wondering how this is created: you can create it yourself if you
# have a complete pytest installation by using this command on the command-
# line: ``py.test --genscript=runtests.py``.
# line: ``pytest --genscript=runtests.py``.
sources = """
@SOURCES@"""

6
doc/en/assert.rst
View File

@ -24,7 +24,7 @@ following::
to assert that your function returns a certain value. If this assertion fails
you will see the return value of the function call::
$ py.test test_assert1.py
$ pytest test_assert1.py
======= test session starts ========
platform linux -- Python 3.5.1, pytest-2.9.2, py-1.4.31, pluggy-0.3.1
rootdir: $REGENDOC_TMPDIR, inifile:
@ -168,7 +168,7 @@ when it encounters comparisons. For example::
if you run this module::
$ py.test test_assert2.py
$ pytest test_assert2.py
======= test session starts ========
platform linux -- Python 3.5.1, pytest-2.9.2, py-1.4.31, pluggy-0.3.1
rootdir: $REGENDOC_TMPDIR, inifile:
@ -237,7 +237,7 @@ now, given this test module::
you can run the test module and get the custom output defined in
the conftest file::
$ py.test -q test_foocompare.py
$ pytest -q test_foocompare.py
F
======= FAILURES ========
_______ test_compare ________

4
doc/en/bash-completion.rst
View File

@ -18,11 +18,11 @@ For global activation of all argcomplete enabled python applications run::
For permanent (but not global) ``pytest`` activation, use::
register-python-argcomplete py.test >> ~/.bashrc
register-python-argcomplete pytest >> ~/.bashrc
For one-time activation of argcomplete for ``pytest`` only, use::
eval "$(register-python-argcomplete py.test)"
eval "$(register-python-argcomplete pytest)"

2
doc/en/builtin.rst
View File

@ -77,7 +77,7 @@ Builtin fixtures/function arguments
You can ask for available builtin or project-custom
:ref:`fixtures <fixtures>` by typing::
$ py.test -q --fixtures
$ pytest -q --fixtures
cache
Return a cache object that can persist state between testing sessions.

20
doc/en/cache.rst
View File

@ -15,7 +15,7 @@ Usage
---------
The plugin provides two command line options to rerun failures from the
last ``py.test`` invocation:
last ``pytest`` invocation:
* ``--lf``, ``--last-failed`` - to only re-run the failures.
* ``--ff``, ``--failed-first`` - to run the failures first and then the rest of
@ -25,7 +25,7 @@ For cleanup (usually not needed), a ``--cache-clear`` option allows to remove
all cross-session cache contents ahead of a test run.
Other plugins may access the `config.cache`_ object to set/get
**json encodable** values between ``py.test`` invocations.
**json encodable** values between ``pytest`` invocations.
.. note::
@ -49,7 +49,7 @@ First, let's create 50 test invocation of which only 2 fail::
If you run this for the first time you will see two failures::
$ py.test -q
$ pytest -q
.................F.......F........................
======= FAILURES ========
_______ test_num[17] ________
@ -78,7 +78,7 @@ If you run this for the first time you will see two failures::
If you then run it with ``--lf``::
$ py.test --lf
$ pytest --lf
======= test session starts ========
platform linux -- Python 3.5.1, pytest-2.9.2, py-1.4.31, pluggy-0.3.1
run-last-failure: rerun last 2 failures
@ -119,7 +119,7 @@ Now, if you run with the ``--ff`` option, all tests will be run but the first
previous failures will be executed first (as can be seen from the series
of ``FF`` and dots)::
$ py.test --ff
$ pytest --ff
======= test session starts ========
platform linux -- Python 3.5.1, pytest-2.9.2, py-1.4.31, pluggy-0.3.1
run-last-failure: rerun last 2 failures first
@ -163,7 +163,7 @@ The new config.cache object
Plugins or conftest.py support code can get a cached value using the
pytest ``config`` object. Here is a basic example plugin which
implements a :ref:`fixture` which re-uses previously created state
across py.test invocations::
across pytest invocations::
# content of test_caching.py
import pytest
@ -184,7 +184,7 @@ across py.test invocations::
If you run this command once, it will take a while because
of the sleep::
$ py.test -q
$ pytest -q
F
======= FAILURES ========
_______ test_function ________
@ -201,7 +201,7 @@ of the sleep::
If you run it a second time the value will be retrieved from
the cache and this will be quick::
$ py.test -q
$ pytest -q
F
======= FAILURES ========
_______ test_function ________
@ -224,7 +224,7 @@ Inspecting Cache content
You can always peek at the content of the cache using the
``--cache-clear`` command line option::
$ py.test --cache-clear
$ pytest --cache-clear
======= test session starts ========
platform linux -- Python 3.5.1, pytest-2.9.2, py-1.4.31, pluggy-0.3.1
rootdir: $REGENDOC_TMPDIR, inifile:
@ -250,7 +250,7 @@ Clearing Cache content
You can instruct pytest to clear all cache files and values
by adding the ``--cache-clear`` option like this::
py.test --cache-clear
pytest --cache-clear
This is recommended for invocations from Continous Integration
servers where isolation and correctness is more important

8
doc/en/capture.rst
View File

@ -36,9 +36,9 @@ There are two ways in which ``pytest`` can perform capturing:
You can influence output capturing mechanisms from the command line::
py.test -s # disable all capturing
py.test --capture=sys # replace sys.stdout/stderr with in-mem files
py.test --capture=fd # also point filedescriptors 1 and 2 to temp file
pytest -s # disable all capturing
pytest --capture=sys # replace sys.stdout/stderr with in-mem files
pytest --capture=fd # also point filedescriptors 1 and 2 to temp file
.. _printdebugging:
@ -62,7 +62,7 @@ is that you can use print statements for debugging::
and running this module will show you precisely the output
of the failing function and hide the other one::
$ py.test
$ pytest
======= test session starts ========
platform linux -- Python 3.5.1, pytest-2.9.2, py-1.4.31, pluggy-0.3.1
rootdir: $REGENDOC_TMPDIR, inifile:

10
doc/en/customize.rst
View File

@ -7,7 +7,7 @@ Command line options and configuration file settings
You can get help on command line options and values in INI-style
configurations files by using the general help option::
py.test -h # prints options _and_ config file settings
pytest -h # prints options _and_ config file settings
This will display command line and configuration file settings
which were registered by installed plugins.
@ -62,7 +62,7 @@ per-testrun information.
Example::
py.test path/to/testdir path/other/
pytest path/to/testdir path/other/
will determine the common ancestor as ``path`` and then
check for ini-files as follows::
@ -126,9 +126,9 @@ Builtin configuration file options
[pytest]
addopts = --maxfail=2 -rf # exit after 2 failures, report fail info
issuing ``py.test test_hello.py`` actually means::
issuing ``pytest test_hello.py`` actually means::
py.test --maxfail=2 -rf test_hello.py
pytest --maxfail=2 -rf test_hello.py
Default is to add no options.
@ -218,7 +218,7 @@ Builtin configuration file options
.. confval:: doctest_optionflags
One or more doctest flag names from the standard ``doctest`` module.
:doc:`See how py.test handles doctests <doctest>`.
:doc:`See how pytest handles doctests <doctest>`.
.. confval:: confcutdir

12
doc/en/doctest.rst
View File

@ -6,7 +6,7 @@ By default all files matching the ``test*.txt`` pattern will
be run through the python standard ``doctest`` module. You
can change the pattern by issuing::
py.test --doctest-glob='*.rst'
pytest --doctest-glob='*.rst'
on the command line. Since version ``2.9``, ``--doctest-glob``
can be given multiple times in the command-line.
@ -15,7 +15,7 @@ You can also trigger running of doctests
from docstrings in all python modules (including regular
python test modules)::
py.test --doctest-modules
pytest --doctest-modules
You can make these changes permanent in your project by
putting them into a pytest.ini file like this:
@ -45,9 +45,9 @@ and another like this::
"""
return 42
then you can just invoke ``py.test`` without command line options::
then you can just invoke ``pytest`` without command line options::
$ py.test
$ pytest
======= test session starts ========
platform linux -- Python 3.5.1, pytest-2.9.2, py-1.4.31, pluggy-0.3.1
rootdir: $REGENDOC_TMPDIR, inifile: pytest.ini
@ -68,7 +68,7 @@ Also, :ref:`usefixtures` and :ref:`autouse` fixtures are supported
when executing text doctest files.
The standard ``doctest`` module provides some setting flags to configure the
strictness of doctest tests. In py.test You can enable those flags those flags
strictness of doctest tests. In pytest You can enable those flags those flags
using the configuration file. To make pytest ignore trailing whitespaces and
ignore lengthy exception stack traces you can just write:
@ -77,7 +77,7 @@ ignore lengthy exception stack traces you can just write:
[pytest]
doctest_optionflags= NORMALIZE_WHITESPACE IGNORE_EXCEPTION_DETAIL
py.test also introduces new options to allow doctests to run in Python 2 and
pytest also introduces new options to allow doctests to run in Python 2 and
Python 3 unchanged:
* ``ALLOW_UNICODE``: when enabled, the ``u`` prefix is stripped from unicode

40
doc/en/example/markers.rst
View File

@ -29,7 +29,7 @@ You can "mark" a test function with custom metadata like this::
You can then restrict a test run to only run tests marked with ``webtest``::
$ py.test -v -m webtest
$ pytest -v -m webtest
======= test session starts ========
platform linux -- Python 3.5.1, pytest-2.9.2, py-1.4.31, pluggy-0.3.1 -- $PYTHON_PREFIX/bin/python3.5
cachedir: .cache
@ -43,7 +43,7 @@ You can then restrict a test run to only run tests marked with ``webtest``::
Or the inverse, running all tests except the webtest ones::
$ py.test -v -m "not webtest"
$ pytest -v -m "not webtest"
======= test session starts ========
platform linux -- Python 3.5.1, pytest-2.9.2, py-1.4.31, pluggy-0.3.1 -- $PYTHON_PREFIX/bin/python3.5
cachedir: .cache
@ -64,7 +64,7 @@ You can provide one or more :ref:`node IDs <node-id>` as positional
arguments to select only specified tests. This makes it easy to select
tests based on their module, class, method, or function name::
$ py.test -v test_server.py::TestClass::test_method
$ pytest -v test_server.py::TestClass::test_method
======= test session starts ========
platform linux -- Python 3.5.1, pytest-2.9.2, py-1.4.31, pluggy-0.3.1 -- $PYTHON_PREFIX/bin/python3.5
cachedir: .cache
@ -77,7 +77,7 @@ tests based on their module, class, method, or function name::
You can also select on the class::
$ py.test -v test_server.py::TestClass
$ pytest -v test_server.py::TestClass
======= test session starts ========
platform linux -- Python 3.5.1, pytest-2.9.2, py-1.4.31, pluggy-0.3.1 -- $PYTHON_PREFIX/bin/python3.5
cachedir: .cache
@ -90,7 +90,7 @@ You can also select on the class::
Or select multiple nodes::
$ py.test -v test_server.py::TestClass test_server.py::test_send_http
$ pytest -v test_server.py::TestClass test_server.py::test_send_http
======= test session starts ========
platform linux -- Python 3.5.1, pytest-2.9.2, py-1.4.31, pluggy-0.3.1 -- $PYTHON_PREFIX/bin/python3.5
cachedir: .cache
@ -115,8 +115,8 @@ Or select multiple nodes::
``module.py::function[param]``.
Node IDs for failing tests are displayed in the test summary info
when running py.test with the ``-rf`` option. You can also
construct Node IDs from the output of ``py.test --collectonly``.
when running pytest with the ``-rf`` option. You can also
construct Node IDs from the output of ``pytest --collectonly``.
Using ``-k expr`` to select tests based on their name
-------------------------------------------------------
@ -128,7 +128,7 @@ which implements a substring match on the test names instead of the
exact match on markers that ``-m`` provides. This makes it easy to
select tests based on their names::
$ py.test -v -k http # running with the above defined example module
$ pytest -v -k http # running with the above defined example module
======= test session starts ========
platform linux -- Python 3.5.1, pytest-2.9.2, py-1.4.31, pluggy-0.3.1 -- $PYTHON_PREFIX/bin/python3.5
cachedir: .cache
@ -142,7 +142,7 @@ select tests based on their names::
And you can also run all tests except the ones that match the keyword::
$ py.test -k "not send_http" -v
$ pytest -k "not send_http" -v
======= test session starts ========
platform linux -- Python 3.5.1, pytest-2.9.2, py-1.4.31, pluggy-0.3.1 -- $PYTHON_PREFIX/bin/python3.5
cachedir: .cache
@ -158,7 +158,7 @@ And you can also run all tests except the ones that match the keyword::
Or to select "http" and "quick" tests::
$ py.test -k "http or quick" -v
$ pytest -k "http or quick" -v
======= test session starts ========
platform linux -- Python 3.5.1, pytest-2.9.2, py-1.4.31, pluggy-0.3.1 -- $PYTHON_PREFIX/bin/python3.5
cachedir: .cache
@ -198,7 +198,7 @@ Registering markers for your test suite is simple::
You can ask which markers exist for your test suite - the list includes our just defined ``webtest`` markers::
$ py.test --markers
$ pytest --markers
@pytest.mark.webtest: mark a test as a webtest.
@pytest.mark.skip(reason=None): skip the given test function with an optional reason. Example: skip(reason="no way of currently testing this") skips the test.
@ -225,7 +225,7 @@ For an example on how to add and work with markers from a plugin, see
* there is one place in your test suite defining your markers
* asking for existing markers via ``py.test --markers`` gives good output
* asking for existing markers via ``pytest --markers`` gives good output
* typos in function markers are treated as an error if you use
the ``--strict`` option. Future versions of ``pytest`` are probably
@ -350,7 +350,7 @@ A test file using this local plugin::
and an example invocations specifying a different environment than what
the test needs::
$ py.test -E stage2
$ pytest -E stage2
======= test session starts ========
platform linux -- Python 3.5.1, pytest-2.9.2, py-1.4.31, pluggy-0.3.1
rootdir: $REGENDOC_TMPDIR, inifile:
@ -362,7 +362,7 @@ the test needs::
and here is one that specifies exactly the environment needed::
$ py.test -E stage1
$ pytest -E stage1
======= test session starts ========
platform linux -- Python 3.5.1, pytest-2.9.2, py-1.4.31, pluggy-0.3.1
rootdir: $REGENDOC_TMPDIR, inifile:
@ -374,7 +374,7 @@ and here is one that specifies exactly the environment needed::
The ``--markers`` option always gives you a list of available markers::
$ py.test --markers
$ pytest --markers
@pytest.mark.env(name): mark test to run only on named environment
@pytest.mark.skip(reason=None): skip the given test function with an optional reason. Example: skip(reason="no way of currently testing this") skips the test.
@ -427,7 +427,7 @@ test function. From a conftest file we can read it like this::
Let's run this without capturing output and see what we get::
$ py.test -q -s
$ pytest -q -s
glob args=('function',) kwargs={'x': 3}
glob args=('class',) kwargs={'x': 2}
glob args=('module',) kwargs={'x': 1}
@ -483,7 +483,7 @@ Let's do a little test file to show how this looks like::
then you will see two test skipped and two executed tests as expected::
$ py.test -rs # this option reports skip reasons
$ pytest -rs # this option reports skip reasons
======= test session starts ========
platform linux -- Python 3.5.1, pytest-2.9.2, py-1.4.31, pluggy-0.3.1
rootdir: $REGENDOC_TMPDIR, inifile:
@ -497,7 +497,7 @@ then you will see two test skipped and two executed tests as expected::
Note that if you specify a platform via the marker-command line option like this::
$ py.test -m linux2
$ pytest -m linux2
======= test session starts ========
platform linux -- Python 3.5.1, pytest-2.9.2, py-1.4.31, pluggy-0.3.1
rootdir: $REGENDOC_TMPDIR, inifile:
@ -549,7 +549,7 @@ We want to dynamically define two markers and can do it in a
We can now use the ``-m option`` to select one set::
$ py.test -m interface --tb=short
$ pytest -m interface --tb=short
======= test session starts ========
platform linux -- Python 3.5.1, pytest-2.9.2, py-1.4.31, pluggy-0.3.1
rootdir: $REGENDOC_TMPDIR, inifile:
@ -571,7 +571,7 @@ We can now use the ``-m option`` to select one set::
or to select both "event" and "interface" tests::
$ py.test -m "interface or event" --tb=short
$ pytest -m "interface or event" --tb=short
======= test session starts ========
platform linux -- Python 3.5.1, pytest-2.9.2, py-1.4.31, pluggy-0.3.1
rootdir: $REGENDOC_TMPDIR, inifile:

6
doc/en/example/nonpython.rst
View File

@ -25,7 +25,7 @@ You can create a simple example file:
and if you installed `PyYAML`_ or a compatible YAML-parser you can
now execute the test specification::
nonpython $ py.test test_simple.yml
nonpython $ pytest test_simple.yml
======= test session starts ========
platform linux -- Python 3.5.1, pytest-2.9.2, py-1.4.31, pluggy-0.3.1
rootdir: $REGENDOC_TMPDIR/nonpython, inifile:
@ -57,7 +57,7 @@ your own domain specific testing language this way.
``reportinfo()`` is used for representing the test location and is also
consulted when reporting in ``verbose`` mode::
nonpython $ py.test -v
nonpython $ pytest -v
======= test session starts ========
platform linux -- Python 3.5.1, pytest-2.9.2, py-1.4.31, pluggy-0.3.1 -- $PYTHON_PREFIX/bin/python3.5
cachedir: .cache
@ -79,7 +79,7 @@ consulted when reporting in ``verbose`` mode::
While developing your custom test collection and execution it's also
interesting to just look at the collection tree::
nonpython $ py.test --collect-only
nonpython $ pytest --collect-only
======= test session starts ========
platform linux -- Python 3.5.1, pytest-2.9.2, py-1.4.31, pluggy-0.3.1
rootdir: $REGENDOC_TMPDIR/nonpython, inifile:

22
doc/en/example/parametrize.rst
View File

@ -44,14 +44,14 @@ Now we add a test configuration like this::
This means that we only run 2 tests if we do not pass ``--all``::
$ py.test -q test_compute.py
$ pytest -q test_compute.py
..
2 passed in 0.12 seconds
We run only two computations, so we see two dots.
let's run the full monty::
$ py.test -q --all
$ pytest -q --all
....F
======= FAILURES ========
_______ test_compute[4] ________
@ -128,7 +128,7 @@ label generated by ``idfn``, but because we didn't generate a label for ``timede
objects, they are still using the default pytest representation::
$ py.test test_time.py --collect-only
$ pytest test_time.py --collect-only
======= test session starts ========
platform linux -- Python 3.5.1, pytest-2.9.2, py-1.4.31, pluggy-0.3.1
rootdir: $REGENDOC_TMPDIR, inifile:
@ -179,7 +179,7 @@ only have to work a bit to construct the correct arguments for pytest's
this is a fully self-contained example which you can run with::
$ py.test test_scenarios.py
$ pytest test_scenarios.py
======= test session starts ========
platform linux -- Python 3.5.1, pytest-2.9.2, py-1.4.31, pluggy-0.3.1
rootdir: $REGENDOC_TMPDIR, inifile:
@ -192,7 +192,7 @@ this is a fully self-contained example which you can run with::
If you just collect tests you'll also nicely see 'advanced' and 'basic' as variants for the test function::
$ py.test --collect-only test_scenarios.py
$ pytest --collect-only test_scenarios.py
======= test session starts ========
platform linux -- Python 3.5.1, pytest-2.9.2, py-1.4.31, pluggy-0.3.1
rootdir: $REGENDOC_TMPDIR, inifile:
@ -257,7 +257,7 @@ creates a database object for the actual test invocations::
Let's first see how it looks like at collection time::
$ py.test test_backends.py --collect-only
$ pytest test_backends.py --collect-only
======= test session starts ========
platform linux -- Python 3.5.1, pytest-2.9.2, py-1.4.31, pluggy-0.3.1
rootdir: $REGENDOC_TMPDIR, inifile:
@ -270,7 +270,7 @@ Let's first see how it looks like at collection time::
And then when we run the test::
$ py.test -q test_backends.py
$ pytest -q test_backends.py
.F
======= FAILURES ========
_______ test_db_initialized[d2] ________
@ -318,7 +318,7 @@ will be passed to respective fixture function::
The result of this test will be successful::
$ py.test test_indirect_list.py --collect-only
$ pytest test_indirect_list.py --collect-only
======= test session starts ========
platform linux -- Python 3.5.1, pytest-2.9.2, py-1.4.31, pluggy-0.3.1
rootdir: $REGENDOC_TMPDIR, inifile:
@ -366,7 +366,7 @@ parametrizer`_ but in a lot less code::
Our test generator looks up a class-level definition which specifies which
argument sets to use for each test function. Let's run it::
$ py.test -q
$ pytest -q
F..
======= FAILURES ========
_______ TestClass.test_equals[1-2] ________
@ -396,7 +396,7 @@ is to be run with different sets of arguments for its three arguments:
Running it results in some skips if we don't have all the python interpreters installed and otherwise runs all combinations (5 interpreters times 5 interpreters times 3 objects to serialize/deserialize)::
. $ py.test -rs -q multipython.py
. $ pytest -rs -q multipython.py
...........................
27 passed in 0.12 seconds
@ -443,7 +443,7 @@ And finally a little test module::
If you run this with reporting for skips enabled::
$ py.test -rs test_module.py
$ pytest -rs test_module.py
======= test session starts ========
platform linux -- Python 3.5.1, pytest-2.9.2, py-1.4.31, pluggy-0.3.1
rootdir: $REGENDOC_TMPDIR, inifile:

2
doc/en/example/pythoncollection.py
View File

@ -1,5 +1,5 @@
# run this with $ py.test --collect-only test_collectonly.py
# run this with $ pytest --collect-only test_collectonly.py
#
def test_function():
pass

12
doc/en/example/pythoncollection.rst
View File

@ -80,7 +80,7 @@ that match ``*_check``. For example, if we have::
then the test collection looks like this::
$ py.test --collect-only
$ pytest --collect-only
======= test session starts ========
platform linux -- Python 3.5.1, pytest-2.9.2, py-1.4.31, pluggy-0.3.1
rootdir: $REGENDOC_TMPDIR, inifile: setup.cfg
@ -107,7 +107,7 @@ interpreting arguments as python package names, deriving
their file system path and then running the test. For
example if you have unittest2 installed you can type::
py.test --pyargs unittest2.test.test_skipping -q
pytest --pyargs unittest2.test.test_skipping -q
which would run the respective test module. Like with
other options, through an ini-file and the :confval:`addopts` option you
@ -117,7 +117,7 @@ can make this change more permanently::
[pytest]
addopts = --pyargs
Now a simple invocation of ``py.test NAME`` will check
Now a simple invocation of ``pytest NAME`` will check
if NAME exists as an importable package/module and otherwise
treat it as a filesystem path.
@ -126,7 +126,7 @@ Finding out what is collected
You can always peek at the collection tree without running tests like this::
. $ py.test --collect-only pythoncollection.py
. $ pytest --collect-only pythoncollection.py
======= test session starts ========
platform linux -- Python 3.5.1, pytest-2.9.2, py-1.4.31, pluggy-0.3.1
rootdir: $REGENDOC_TMPDIR, inifile: pytest.ini
@ -180,7 +180,7 @@ and a setup.py dummy file like this::
then a pytest run on Python2 will find the one test and will leave out the
setup.py file::
#$ py.test --collect-only
#$ pytest --collect-only
====== test session starts ======
platform linux2 -- Python 2.7.10, pytest-2.9.1, py-1.4.31, pluggy-0.3.1
rootdir: $REGENDOC_TMPDIR, inifile: pytest.ini
@ -193,7 +193,7 @@ setup.py file::
If you run with a Python3 interpreter both the one test and the setup.py file
will be left out::
$ py.test --collect-only
$ pytest --collect-only
======= test session starts ========
platform linux -- Python 3.5.1, pytest-2.9.2, py-1.4.31, pluggy-0.3.1
rootdir: $REGENDOC_TMPDIR, inifile: pytest.ini

2
doc/en/example/reportingdemo.rst
View File

@ -11,7 +11,7 @@ get on the terminal - we are working on that):
.. code-block:: python
assertion $ py.test failure_demo.py
assertion $ pytest failure_demo.py
======= test session starts ========
platform linux -- Python 3.5.1, pytest-2.9.2, py-1.4.31, pluggy-0.3.1
rootdir: $REGENDOC_TMPDIR/assertion, inifile:

32
doc/en/example/simple.rst
View File

@ -37,7 +37,7 @@ provide the ``cmdopt`` through a :ref:`fixture function <fixture function>`::
Let's run this without supplying our new option::
$ py.test -q test_sample.py
$ pytest -q test_sample.py
F
======= FAILURES ========
_______ test_answer ________
@ -59,7 +59,7 @@ Let's run this without supplying our new option::
And now with supplying a command line option::
$ py.test -q --cmdopt=type2
$ pytest -q --cmdopt=type2
F
======= FAILURES ========
_______ test_answer ________
@ -106,7 +106,7 @@ you will now always perform test runs using a number
of subprocesses close to your CPU. Running in an empty
directory with the above conftest.py::
$ py.test
$ pytest
======= test session starts ========
platform linux -- Python 3.5.1, pytest-2.9.2, py-1.4.31, pluggy-0.3.1
rootdir: $REGENDOC_TMPDIR, inifile:
@ -154,7 +154,7 @@ We can now write a test module like this::
and when running it will see a skipped "slow" test::
$ py.test -rs # "-rs" means report details on the little 's'
$ pytest -rs # "-rs" means report details on the little 's'
======= test session starts ========
platform linux -- Python 3.5.1, pytest-2.9.2, py-1.4.31, pluggy-0.3.1
rootdir: $REGENDOC_TMPDIR, inifile:
@ -168,7 +168,7 @@ and when running it will see a skipped "slow" test::
Or run it including the ``slow`` marked test::
$ py.test --runslow
$ pytest --runslow
======= test session starts ========
platform linux -- Python 3.5.1, pytest-2.9.2, py-1.4.31, pluggy-0.3.1
rootdir: $REGENDOC_TMPDIR, inifile:
@ -204,7 +204,7 @@ of tracebacks: the ``checkconfig`` function will not be shown
unless the ``--full-trace`` command line option is specified.
Let's run our little function::
$ py.test -q test_checkconfig.py
$ pytest -q test_checkconfig.py
F
======= FAILURES ========
_______ test_something ________
@ -282,7 +282,7 @@ It's easy to present extra information in a ``pytest`` run::
which will add the string to the test header accordingly::
$ py.test
$ pytest
======= test session starts ========
platform linux -- Python 3.5.1, pytest-2.9.2, py-1.4.31, pluggy-0.3.1
project deps: mylib-1.1
@ -306,7 +306,7 @@ you present more information appropriately::
which will add info only when run with "--v"::
$ py.test -v
$ pytest -v
======= test session starts ========
platform linux -- Python 3.5.1, pytest-2.9.2, py-1.4.31, pluggy-0.3.1 -- $PYTHON_PREFIX/bin/python3.5
cachedir: .cache
@ -319,7 +319,7 @@ which will add info only when run with "--v"::
and nothing when run plainly::
$ py.test
$ pytest
======= test session starts ========
platform linux -- Python 3.5.1, pytest-2.9.2, py-1.4.31, pluggy-0.3.1
rootdir: $REGENDOC_TMPDIR, inifile:
@ -352,7 +352,7 @@ out which tests are the slowest. Let's make an artificial test suite::
Now we can profile which test functions execute the slowest::
$ py.test --durations=3
$ pytest --durations=3
======= test session starts ========
platform linux -- Python 3.5.1, pytest-2.9.2, py-1.4.31, pluggy-0.3.1
rootdir: $REGENDOC_TMPDIR, inifile:
@ -414,7 +414,7 @@ tests in a class. Here is a test module example::
If we run this::
$ py.test -rx
$ pytest -rx
======= test session starts ========
platform linux -- Python 3.5.1, pytest-2.9.2, py-1.4.31, pluggy-0.3.1
rootdir: $REGENDOC_TMPDIR, inifile:
@ -485,7 +485,7 @@ the ``db`` fixture::
We can run this::
$ py.test
$ pytest
======= test session starts ========
platform linux -- Python 3.5.1, pytest-2.9.2, py-1.4.31, pluggy-0.3.1
rootdir: $REGENDOC_TMPDIR, inifile:
@ -502,7 +502,7 @@ We can run this::
def test_root(db): # no db here, will error out
fixture 'db' not found
available fixtures: tmpdir_factory, cache, tmpdir, pytestconfig, recwarn, monkeypatch, capfd, record_xml_property, capsys
use 'py.test --fixtures [testpath]' for help on them.
use 'pytest --fixtures [testpath]' for help on them.
$REGENDOC_TMPDIR/b/test_error.py:1
======= FAILURES ========
@ -589,7 +589,7 @@ if you then have failing tests::
and run them::
$ py.test test_module.py
$ pytest test_module.py
======= test session starts ========
platform linux -- Python 3.5.1, pytest-2.9.2, py-1.4.31, pluggy-0.3.1
rootdir: $REGENDOC_TMPDIR, inifile:
@ -679,7 +679,7 @@ if you then have failing tests::
and run it::
$ py.test -s test_module.py
$ pytest -s test_module.py
======= test session starts ========
platform linux -- Python 3.5.1, pytest-2.9.2, py-1.4.31, pluggy-0.3.1
rootdir: $REGENDOC_TMPDIR, inifile:
@ -767,6 +767,6 @@ over to ``pytest`` instead. For example::
...
This makes it convenient to execute your tests from within your frozen
application, using standard ``py.test`` command-line options::
application, using standard ``pytest`` command-line options::
./app_main --pytest --verbose --tb=long --junitxml=results.xml test-suite/

2
doc/en/example/special.rst
View File

@ -59,7 +59,7 @@ will be called ahead of running any tests::
If you run this without output capturing::
$ py.test -q -s test_module.py
$ pytest -q -s test_module.py
callattr_ahead_of_alltests called
callme called!
callme other called

21
doc/en/faq.rst
View File

@ -81,18 +81,17 @@ You can also turn off all assertion interaction using the
.. _`py/__init__.py`: http://bitbucket.org/hpk42/py-trunk/src/trunk/py/__init__.py
Why a ``py.test`` instead of a ``pytest`` command?
++++++++++++++++++++++++++++++++++++++++++++++++++
Why can I use both ``pytest`` and ``py.test`` commands?
+++++++++++++++++++++++++++++++++++++++++++++++++++++++
Some of the reasons are historic, others are practical. ``pytest``
used to be part of the ``py`` package which provided several developer
utilities, all starting with ``py.<TAB>``, thus providing nice
TAB-completion. If
you install ``pip install pycmd`` you get these tools from a separate
package. These days the command line tool could be called ``pytest``
but since many people have gotten used to the old name and there
is another tool named "pytest" we just decided to stick with
``py.test`` for now.
pytest used to be part of the py package, which provided several developer
utilities, all starting with ``py.<TAB>``, thus providing nice TAB-completion.
If you install ``pip install pycmd`` you get these tools from a separate
package. Once ``pytest`` became a separate package, the ``py.test`` name was
retained due to avoid a naming conflict with another tool. This conflict was
eventually resolved, and the ``pytest`` command was therefore introduced. In
future versions of pytest, we may deprecate and later remove the ``py.test``
command to avoid perpetuating the confusion.
pytest fixtures, parametrized tests
-------------------------------------------------------

24
doc/en/fixture.rst
View File

@ -68,7 +68,7 @@ Here, the ``test_ehlo`` needs the ``smtp`` fixture value. pytest
will discover and call the :py:func:`@pytest.fixture <_pytest.python.fixture>`
marked ``smtp`` fixture function. Running the test looks like this::
$ py.test test_smtpsimple.py
$ pytest test_smtpsimple.py
======= test session starts ========
platform linux -- Python 3.5.1, pytest-2.9.2, py-1.4.31, pluggy-0.3.1
rootdir: $REGENDOC_TMPDIR, inifile:
@ -113,7 +113,7 @@ with a list of available function arguments.
You can always issue::
py.test --fixtures test_simplefactory.py
pytest --fixtures test_simplefactory.py
to see available fixtures.
@ -186,7 +186,7 @@ function (in or below the directory where ``conftest.py`` is located)::
We deliberately insert failing ``assert 0`` statements in order to
inspect what is going on and can now run the tests::
$ py.test test_module.py
$ pytest test_module.py
======= test session starts ========
platform linux -- Python 3.5.1, pytest-2.9.2, py-1.4.31, pluggy-0.3.1
rootdir: $REGENDOC_TMPDIR, inifile:
@ -262,7 +262,7 @@ the fixture in the module has finished execution, regardless of the exception st
Let's execute it::
$ py.test -s -q --tb=no
$ pytest -s -q --tb=no
FFteardown smtp
2 failed in 0.12 seconds
@ -350,7 +350,7 @@ We use the ``request.module`` attribute to optionally obtain an
``smtpserver`` attribute from the test module. If we just execute
again, nothing much has changed::
$ py.test -s -q --tb=no
$ pytest -s -q --tb=no
FFfinalizing <smtplib.SMTP object at 0xdeadbeef> (smtp.gmail.com)
2 failed in 0.12 seconds
@ -367,7 +367,7 @@ server URL in its module namespace::
Running it::
$ py.test -qq --tb=short test_anothersmtp.py
$ pytest -qq --tb=short test_anothersmtp.py
F
======= FAILURES ========
_______ test_showhelo ________
@ -414,7 +414,7 @@ for each of which the fixture function will execute and can access
a value via ``request.param``. No test function code needs to change.
So let's just do another run::
$ py.test -q test_module.py
$ pytest -q test_module.py
FFFF
======= FAILURES ========
_______ test_ehlo[smtp.gmail.com] ________
@ -514,7 +514,7 @@ return ``None`` then pytest's auto-generated ID will be used.
Running the above tests results in the following test IDs being used::
$ py.test --collect-only
$ pytest --collect-only
======= test session starts ========
platform linux -- Python 3.5.1, pytest-2.9.2, py-1.4.31, pluggy-0.3.1
rootdir: $REGENDOC_TMPDIR, inifile:
@ -565,7 +565,7 @@ and instantiate an object ``app`` where we stick the already defined
Here we declare an ``app`` fixture which receives the previously defined
``smtp`` fixture and instantiates an ``App`` object with it. Let's run it::
$ py.test -v test_appsetup.py
$ pytest -v test_appsetup.py
======= test session starts ========
platform linux -- Python 3.5.1, pytest-2.9.2, py-1.4.31, pluggy-0.3.1 -- $PYTHON_PREFIX/bin/python3.5
cachedir: .cache
@ -634,7 +634,7 @@ to show the setup/teardown flow::
Let's run the tests in verbose mode and with looking at the print-output::
$ py.test -v -s test_module.py
$ pytest -v -s test_module.py
======= test session starts ========
platform linux -- Python 3.5.1, pytest-2.9.2, py-1.4.31, pluggy-0.3.1 -- $PYTHON_PREFIX/bin/python3.5
cachedir: .cache
@ -736,7 +736,7 @@ will be required for the execution of each test method, just as if
you specified a "cleandir" function argument to each of them. Let's run it
to verify our fixture is activated and the tests pass::
$ py.test -q
$ pytest -q
..
2 passed in 0.12 seconds
@ -817,7 +817,7 @@ class-level ``usefixtures`` decorator.
If we run it, we get two passing tests::
$ py.test -q
$ pytest -q
..
2 passed in 0.12 seconds

4
doc/en/funcarg_compare.rst
View File

@ -180,9 +180,9 @@ and obsolete many prior uses of pytest hooks.
funcargs/fixture discovery now happens at collection time
---------------------------------------------------------------------
pytest-2.3 takes care to discover fixture/funcarg factories
Since pytest-2.3, discovery of fixture/funcarg factories are taken care of
at collection time. This is more efficient especially for large test suites.
Moreover, a call to "py.test --collect-only" should be able to in the future
Moreover, a call to "pytest --collect-only" should be able to in the future
show a lot of setup-information and thus presents a nice method to get an
overview of fixture management in your project.

20
doc/en/getting-started.rst
View File

@ -26,7 +26,7 @@ Installation options::
To check your installation has installed the correct version::
$ py.test --version
$ pytest --version
This is pytest version 2.9.2, imported from $PYTHON_PREFIX/lib/python3.5/site-packages/pytest.py
If you get an error checkout :ref:`installation issues`.
@ -47,7 +47,7 @@ Let's create a first test file with a simple test function::
That's it. You can execute the test function now::
$ py.test
$ pytest
======= test session starts ========
platform linux -- Python 3.5.1, pytest-2.9.2, py-1.4.31, pluggy-0.3.1
rootdir: $REGENDOC_TMPDIR, inifile:
@ -102,7 +102,7 @@ use the ``raises`` helper::
Running it with, this time in "quiet" reporting mode::
$ py.test -q test_sysexit.py
$ pytest -q test_sysexit.py
.
1 passed in 0.12 seconds
@ -127,7 +127,7 @@ The two tests are found because of the standard :ref:`test discovery`.
There is no need to subclass anything. We can simply
run the module by passing its filename::
$ py.test -q test_class.py
$ pytest -q test_class.py
.F
======= FAILURES ========
_______ TestClass.test_two ________
@ -163,7 +163,7 @@ We list the name ``tmpdir`` in the test function signature and
``pytest`` will lookup and call a fixture factory to create the resource
before performing the test function call. Let's just run it::
$ py.test -q test_tmpdir.py
$ pytest -q test_tmpdir.py
F
======= FAILURES ========
_______ test_needsfiles ________
@ -185,7 +185,7 @@ was created. More info at :ref:`tmpdir handling`.
You can find out what kind of builtin :ref:`fixtures` exist by typing::
py.test --fixtures # shows builtin and custom fixtures
pytest --fixtures # shows builtin and custom fixtures
Where to go next
-------------------------------------
@ -213,12 +213,12 @@ easy_install or pip not found?
Install `setuptools`_ to get ``easy_install`` which allows to install
``.egg`` binary format packages in addition to source-based ones.
py.test not found on Windows despite installation?
pytest not found on Windows despite installation?
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
.. _`Python for Windows`: http://www.imladris.com/Scripts/PythonForWindows.html
- **Windows**: If "easy_install" or "py.test" are not found
- **Windows**: If "easy_install" or "pytest" are not found
you need to add the Python script path to your ``PATH``, see here:
`Python for Windows`_. You may alternatively use an `ActivePython install`_
which does this for you automatically.
@ -228,8 +228,8 @@ py.test not found on Windows despite installation?
.. _`Jython does not create command line launchers`: http://bugs.jython.org/issue1491
- **Jython2.5.1 on Windows XP**: `Jython does not create command line launchers`_
so ``py.test`` will not work correctly. You may install py.test on
CPython and type ``py.test --genscript=mytest`` and then use
so ``pytest`` will not work correctly. You may install pytest on
CPython and type ``pytest --genscript=mytest`` and then use
``jython mytest`` to run your tests with Jython using ``pytest``.
:ref:`examples` for more complex examples

18
doc/en/goodpractices.rst
View File

@ -72,17 +72,17 @@ Important notes relating to both schemes:
- With inlined tests you might put ``__init__.py`` into test
directories and make them installable as part of your application.
Using the ``py.test --pyargs mypkg`` invocation pytest will
Using the ``pytest --pyargs mypkg`` invocation pytest will
discover where mypkg is installed and collect tests from there.
With the "external" test you can still distribute tests but they
will not be installed or become importable.
Typically you can run tests by pointing to test directories or modules::
py.test tests/test_app.py # for external test dirs
py.test mypkg/test/test_app.py # for inlined test dirs
py.test mypkg # run tests in all below test directories
py.test # run all tests below current dir
pytest tests/test_app.py # for external test dirs
pytest mypkg/test/test_app.py # for inlined test dirs
pytest mypkg # run tests in all below test directories
pytest # run all tests below current dir
...
Because of the above ``editable install`` mode you can change your
@ -193,7 +193,7 @@ If you now type::
this will execute your tests using ``pytest-runner``. As this is a
standalone version of ``pytest`` no prior installation whatsoever is
required for calling the test command. You can also pass additional
arguments to py.test such as your test directory or other
arguments to pytest such as your test directory or other
options using ``--addopts``.
@ -211,7 +211,7 @@ your own setuptools Test command for invoking pytest.
class PyTest(TestCommand):
user_options = [('pytest-args=', 'a', "Arguments to pass to py.test")]
user_options = [('pytest-args=', 'a', "Arguments to pass to pytest")]
def initialize_options(self):
TestCommand.initialize_options(self)
@ -240,7 +240,7 @@ using the ``--pytest-args`` or ``-a`` command-line option. For example::
python setup.py test -a "--durations=5"
is equivalent to running ``py.test --durations=5``.
is equivalent to running ``pytest --durations=5``.
.. _standalone:
@ -268,7 +268,7 @@ If you are a maintainer or application developer and want people
who don't deal with python much to easily run tests you may generate
a standalone ``pytest`` script::
py.test --genscript=runtests.py
pytest --genscript=runtests.py
This generates a ``runtests.py`` script which is a fully functional basic
``pytest`` script, running unchanged under Python2 and Python3.

2
doc/en/nose.rst
View File

@ -13,7 +13,7 @@ Usage
After :ref:`installation` type::
python setup.py develop # make sure tests can import our package
py.test # instead of 'nosetests'
pytest # instead of 'nosetests'
and you should be able to run your nose style tests and
make use of pytest's capabilities.

10
doc/en/parametrize.rst
View File

@ -53,7 +53,7 @@ Here, the ``@parametrize`` decorator defines three different ``(test_input,expec
tuples so that the ``test_eval`` function will run three times using
them in turn::
$ py.test
$ pytest
======= test session starts ========
platform linux -- Python 3.5.1, pytest-2.9.2, py-1.4.31, pluggy-0.3.1
rootdir: $REGENDOC_TMPDIR, inifile:
@ -101,7 +101,7 @@ for example with the builtin ``mark.xfail``::
Let's run this::
$ py.test
$ pytest
======= test session starts ========
platform linux -- Python 3.5.1, pytest-2.9.2, py-1.4.31, pluggy-0.3.1
rootdir: $REGENDOC_TMPDIR, inifile:
@ -171,13 +171,13 @@ command line option and the parametrization of our test function::
If we now pass two stringinput values, our test will run twice::
$ py.test -q --stringinput="hello" --stringinput="world" test_strings.py
$ pytest -q --stringinput="hello" --stringinput="world" test_strings.py
..
2 passed in 0.12 seconds
Let's also run with a stringinput that will lead to a failing test::
$ py.test -q --stringinput="!" test_strings.py
$ pytest -q --stringinput="!" test_strings.py
F
======= FAILURES ========
_______ test_valid_string[!] ________
@ -198,7 +198,7 @@ If you don't specify a stringinput it will be skipped because
``metafunc.parametrize()`` will be called with an empty parameter
list::
$ py.test -q -rs test_strings.py
$ pytest -q -rs test_strings.py
s
======= short test summary info ========
SKIP [1] test_strings.py:1: got empty parameter set ['stringinput'], function test_valid_string at $REGENDOC_TMPDIR/test_strings.py:1

6
doc/en/plugins.rst
View File

@ -59,7 +59,7 @@ Here is a little annotated list for some popular plugins:
a plugin to run javascript unittests in live browsers.
To see a complete list of all plugins with their latest testing
status against different py.test and Python versions, please visit
status against different pytest and Python versions, please visit
`plugincompat <http://plugincompat.herokuapp.com/>`_.
You may also discover more plugins through a `pytest- pypi.python.org search`_.
@ -90,7 +90,7 @@ Finding out which plugins are active
If you want to find out which plugins are active in your
environment you can type::
py.test --trace-config
pytest --trace-config
and will get an extended test header which shows activated plugins
and their names. It will also print local plugins aka
@ -103,7 +103,7 @@ Deactivating / unregistering a plugin by name
You can prevent plugins from loading or unregister them::
py.test -p no:NAME
pytest -p no:NAME
This means that any subsequent try to activate/load the named
plugin will not work.

6
doc/en/skipping.rst
View File

@ -19,7 +19,7 @@ information about skipped/xfailed tests is not shown by default to avoid
cluttering the output. You can use the ``-r`` option to see details
corresponding to the "short" letters shown in the test progress::
py.test -rxs # show extra info on skips and xfails
pytest -rxs # show extra info on skips and xfails
(See :ref:`how to change command line options defaults`)
@ -222,7 +222,7 @@ Here is a simple test file with the several usages:
Running it with the report-on-xfail option gives this output::
example $ py.test -rx xfail_demo.py
example $ pytest -rx xfail_demo.py
======= test session starts ========
platform linux -- Python 3.5.1, pytest-2.9.2, py-1.4.31, pluggy-0.3.1
rootdir: $REGENDOC_TMPDIR/example, inifile:
@ -368,6 +368,6 @@ The equivalent with "boolean conditions" is::
.. note::
You cannot use ``pytest.config.getvalue()`` in code
imported before py.test's argument parsing takes place. For example,
imported before pytest's argument parsing takes place. For example,
``conftest.py`` files are imported before command line parsing and thus
``config.getvalue()`` will not execute correctly.

2
doc/en/test/attic.rst
View File

@ -21,7 +21,7 @@ but note that project specific settings will be considered
first. There is a flag that helps you debugging your
conftest.py configurations::
py.test --trace-config
pytest --trace-config
customizing the collecting and running process

2
doc/en/test/mission.rst
View File

@ -5,7 +5,7 @@ Mission
``pytest`` strives to make testing a fun and no-boilerplate effort.
The tool is distributed as a `pytest` package. Its project independent
``py.test`` command line tool helps you to:
``pytest`` command line tool helps you to:
* rapidly collect and run tests
* run unit- or doctests, functional or integration tests

14
doc/en/test/plugin/cov.rst
View File

@ -53,7 +53,7 @@ subprocesses.
Running centralised testing::
py.test --cov myproj tests/
pytest --cov myproj tests/
Shows a terminal report::
@ -76,7 +76,7 @@ file system. Each slave will have it's subprocesses measured.
Running distributed testing with dist mode set to load::
py.test --cov myproj -n 2 tests/
pytest --cov myproj -n 2 tests/
Shows a terminal report::
@ -92,7 +92,7 @@ Shows a terminal report::
Again but spread over different hosts and different directories::
py.test --cov myproj --dist load
pytest --cov myproj --dist load
--tx ssh=memedough@host1//chdir=testenv1
--tx ssh=memedough@host2//chdir=/tmp/testenv2//python=/tmp/env1/bin/python
--rsyncdir myproj --rsyncdir tests --rsync examples
@ -119,7 +119,7 @@ environments.
Running distributed testing with dist mode set to each::
py.test --cov myproj --dist each
pytest --cov myproj --dist each
--tx popen//chdir=/tmp/testenv3//python=/usr/local/python27/bin/python
--tx ssh=memedough@host2//chdir=/tmp/testenv4//python=/tmp/env2/bin/python
--rsyncdir myproj --rsyncdir tests --rsync examples
@ -149,7 +149,7 @@ annotated source code.
The terminal report without line numbers (default)::
py.test --cov-report term --cov myproj tests/
pytest --cov-report term --cov myproj tests/
-------------------- coverage: platform linux2, python 2.6.4-final-0 ---------------------
Name Stmts Miss Cover
@ -163,7 +163,7 @@ The terminal report without line numbers (default)::
The terminal report with line numbers::
py.test --cov-report term-missing --cov myproj tests/
pytest --cov-report term-missing --cov myproj tests/
-------------------- coverage: platform linux2, python 2.6.4-final-0 ---------------------
Name Stmts Miss Cover Missing
@ -178,7 +178,7 @@ The terminal report with line numbers::
The remaining three reports output to files without showing anything on the terminal (useful for
when the output is going to a continuous integration server)::
py.test --cov-report html --cov-report xml --cov-report annotate --cov myproj tests/
pytest --cov-report html --cov-report xml --cov-report annotate --cov myproj tests/
Coverage Data File

2
doc/en/test/plugin/coverage.rst
View File

@ -26,7 +26,7 @@ Usage
To get full test coverage reports for a particular package type::
py.test --cover-report=report
pytest --cover-report=report
command line options
--------------------

2
doc/en/test/plugin/figleaf.rst
View File

@ -24,7 +24,7 @@ Usage
After installation you can simply type::
py.test --figleaf [...]
pytest --figleaf [...]
to enable figleaf coverage in your test run. A default ".figleaf" data file
and "html" directory will be created. You can use command line options

4
doc/en/test/plugin/nose.rst
View File

@ -14,7 +14,7 @@ Usage
type::
py.test # instead of 'nosetests'
pytest # instead of 'nosetests'
and you should be able to run nose style tests and at the same
time can make full use of pytest's capabilities.
@ -38,7 +38,7 @@ Unsupported idioms / issues
If you find other issues or have suggestions please run::
py.test --pastebin=all
pytest --pastebin=all
and send the resulting URL to a ``pytest`` contact channel,
at best to the mailing list.

10
doc/en/test/plugin/xdist.rst
View File

@ -36,7 +36,7 @@ Speed up test runs by sending tests to multiple CPUs
To send tests to multiple CPUs, type::
py.test -n NUM
pytest -n NUM
Especially for longer running tests or tests requiring
a lot of IO this can lead to considerable speed ups.
@ -47,7 +47,7 @@ Running tests in a Python subprocess
To instantiate a python2.4 sub process and send tests to it, you may type::
py.test -d --tx popen//python=python2.4
pytest -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.
@ -68,7 +68,7 @@ tests that you can successfully run locally. And you
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
pytest -d --tx ssh=myhostpopen --rsyncdir mypkg mypkg
This will synchronize your ``mypkg`` package directory
to an remote ssh account and then locally collect tests
@ -97,7 +97,7 @@ It will tell you that it starts listening on the default
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
pytest -d --tx socket=192.168.1.102:8888 --rsyncdir mypkg mypkg
.. _`atonce`:
@ -107,7 +107,7 @@ 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
pytest --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

4
doc/en/tmpdir.rst
View File

@ -27,7 +27,7 @@ and more. Here is an example test usage::
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
$ pytest test_tmpdir.py
======= test session starts ========
platform linux -- Python 3.5.1, pytest-2.9.2, py-1.4.31, pluggy-0.3.1
rootdir: $REGENDOC_TMPDIR, inifile:
@ -100,7 +100,7 @@ than 3 temporary directories will be removed.
You can override the default temporary directory setting like this::
py.test --basetemp=mydir
pytest --basetemp=mydir
When distributing tests on the local machine, ``pytest`` takes care to
configure a basetemp directory for the sub processes such that all temporary

6
doc/en/unittest.rst
View File

@ -21,7 +21,7 @@ Usage
After :ref:`installation` type::
py.test
pytest
and you should be able to run your unittest-style tests if they
are contained in ``test_*`` modules. If that works for you then
@ -86,7 +86,7 @@ the pytest fixture function ``db_class`` is called once per class.
Due to the deliberately failing assert statements, we can take a look at
the ``self.db`` values in the traceback::
$ py.test test_unittest_db.py
$ pytest test_unittest_db.py
======= test session starts ========
platform linux -- Python 3.5.1, pytest-2.9.2, py-1.4.31, pluggy-0.3.1
rootdir: $REGENDOC_TMPDIR, inifile:
@ -161,7 +161,7 @@ on the class like in the previous example.
Running this test module ...::
$ py.test -q test_unittest_cleandir.py
$ pytest -q test_unittest_cleandir.py
.
1 passed in 0.12 seconds

66
doc/en/usage.rst
View File

@ -16,7 +16,7 @@ You can invoke testing through the Python interpreter from the command line::
python -m pytest [...]
This is equivalent to invoking the command line script ``py.test [...]``
This is equivalent to invoking the command line script ``pytest [...]``
directly.
Getting help on version, option names, environment variables
@ -24,9 +24,9 @@ Getting help on version, option names, environment variables
::
py.test --version # shows where pytest was imported from
py.test --fixtures # show available builtin function arguments
py.test -h | --help # show help on command line and config file options
pytest --version # shows where pytest was imported from
pytest --fixtures # show available builtin function arguments
pytest -h | --help # show help on command line and config file options
Stopping after the first (or N) failures
@ -34,45 +34,45 @@ Stopping after the first (or N) failures
To stop the testing process after the first (N) failures::
py.test -x # stop after first failure
py.test --maxfail=2 # stop after two failures
pytest -x # stop after first failure
pytest --maxfail=2 # stop after two failures
Specifying tests / selecting tests
---------------------------------------------------
Several test run options::
py.test test_mod.py # run tests in module
py.test somepath # run all tests below somepath
py.test -k stringexpr # only run tests with names that match the
pytest test_mod.py # run tests in module
pytest somepath # run all tests below somepath
pytest -k stringexpr # only run tests with names that match the
# "string expression", e.g. "MyClass and not method"
# will select TestMyClass.test_something
# but not TestMyClass.test_method_simple
py.test test_mod.py::test_func # only run tests that match the "node ID",
pytest test_mod.py::test_func # only run tests that match the "node ID",
# e.g "test_mod.py::test_func" will select
# only test_func in test_mod.py
py.test test_mod.py::TestClass::test_method # run a single method in
pytest test_mod.py::TestClass::test_method # run a single method in
# a single class
Import 'pkg' and use its filesystem location to find and run tests::
py.test --pyargs pkg # run all tests found below directory of pkg
pytest --pyargs pkg # run all tests found below directory of pkg
Modifying Python traceback printing
----------------------------------------------
Examples for modifying traceback printing::
py.test --showlocals # show local variables in tracebacks
py.test -l # show local variables (shortcut)
pytest --showlocals # show local variables in tracebacks
pytest -l # show local variables (shortcut)
py.test --tb=auto # (default) 'long' tracebacks for the first and last
pytest --tb=auto # (default) 'long' tracebacks for the first and last
# entry, but 'short' style for the other entries
py.test --tb=long # exhaustive, informative traceback formatting
py.test --tb=short # shorter traceback format
py.test --tb=line # only one line per failure
py.test --tb=native # Python standard library formatting
py.test --tb=no # no traceback at all
pytest --tb=long # exhaustive, informative traceback formatting
pytest --tb=short # shorter traceback format
pytest --tb=line # only one line per failure
pytest --tb=native # Python standard library formatting
pytest --tb=no # no traceback at all
The ``--full-trace`` causes very long traces to be printed on error (longer
than ``--tb=long``). It also ensures that a stack trace is printed on
@ -90,14 +90,14 @@ Dropping to PDB_ (Python Debugger) on failures
Python comes with a builtin Python debugger called PDB_. ``pytest``
allows one to drop into the PDB_ prompt via a command line option::
py.test --pdb
pytest --pdb
This will invoke the Python debugger on every failure. Often you might
only want to do this for the first failing test to understand a certain
failure situation::
py.test -x --pdb # drop to PDB on first failure, then end test session
py.test --pdb --maxfail=3 # drop to PDB for first three failures
pytest -x --pdb # drop to PDB on first failure, then end test session
pytest --pdb --maxfail=3 # drop to PDB for first three failures
Note that on any failure the exception information is stored on
``sys.last_value``, ``sys.last_type`` and ``sys.last_traceback``. In
@ -125,7 +125,7 @@ can use a helper::
.. versionadded: 2.0.0
Prior to pytest version 2.0.0 you could only enter PDB_ tracing if you disabled
capturing on the command line via ``py.test -s``. In later versions, pytest
capturing on the command line via ``pytest -s``. In later versions, pytest
automatically disables its output capture when you enter PDB_ tracing:
* Output capture in other tests is not affected.
@ -141,7 +141,7 @@ automatically disables its output capture when you enter PDB_ tracing:
Since pytest version 2.4.0 you can also use the native Python
``import pdb;pdb.set_trace()`` call to enter PDB_ tracing without having to use
the ``pytest.set_trace()`` wrapper or explicitly disable pytest's output
capturing via ``py.test -s``.
capturing via ``pytest -s``.
.. _durations:
@ -152,7 +152,7 @@ Profiling test execution duration
To get a list of the slowest 10 test durations::
py.test --durations=10
pytest --durations=10
Creating JUnitXML format files
@ -161,7 +161,7 @@ Creating JUnitXML format files
To create result files which can be read by Jenkins_ or other Continuous
integration servers, use this invocation::
py.test --junitxml=path
pytest --junitxml=path
to create an XML file at ``path``.
@ -253,7 +253,7 @@ Creating resultlog format files
To create plain-text machine-readable result files you can issue::
py.test --resultlog=path
pytest --resultlog=path
and look at the content at the ``path`` location. Such files are used e.g.
by the `PyPy-test`_ web page to show test results over several revisions.
@ -266,7 +266,7 @@ Sending test report to online pastebin service
**Creating a URL for each test failure**::
py.test --pastebin=failed
pytest --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
@ -274,7 +274,7 @@ 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
pytest --pastebin=all
Currently only pasting to the http://bpaste.net service is implemented.
@ -285,9 +285,9 @@ To disable loading specific plugins at invocation time, use the ``-p`` option
together with the prefix ``no:``.
Example: to disable loading the plugin ``doctest``, which is responsible for
executing doctest tests from text files, invoke py.test like this::
executing doctest tests from text files, invoke pytest like this::
py.test -p no:doctest
pytest -p no:doctest
.. _`pytest.main-usage`:
@ -300,7 +300,7 @@ You can invoke ``pytest`` from Python code directly::
pytest.main()
this acts as if you would call "py.test" from the command line.
this acts as if you would call "pytest" from the command line.
It will not raise ``SystemExit`` but return the exitcode instead.
You can pass in options and arguments::

4
doc/en/writing_plugins.rst
View File

@ -87,8 +87,8 @@ sub directory but not for other directories::
Here is how you might run it::
py.test test_flat.py # will not show "setting up"
py.test a/test_sub.py # will show "setting up"
pytest test_flat.py # will not show "setting up"
pytest a/test_sub.py # will show "setting up"
.. Note::
If you have ``conftest.py`` files which do not reside in a

16
doc/en/xdist.rst
View File

@ -52,7 +52,7 @@ Speed up test runs by sending tests to multiple CPUs
To send tests to multiple CPUs, type::
py.test -n NUM
pytest -n NUM
Especially for longer running tests or tests requiring
a lot of I/O this can lead to considerable speed ups.
@ -63,14 +63,14 @@ Running tests in a Python subprocess
To instantiate a Python-2.7 subprocess and send tests to it, you may type::
py.test -d --tx popen//python=python2.7
pytest -d --tx popen//python=python2.7
This will start a subprocess which is run with the "python2.7"
Python interpreter, found in your system binary lookup path.
If you prefix the --tx option value like this::
py.test -d --tx 3*popen//python=python2.7
pytest -d --tx 3*popen//python=python2.7
then three subprocesses would be created and the tests
will be distributed to three subprocesses and run simultanously.
@ -84,7 +84,7 @@ Running tests in looponfailing mode
For refactoring a project with a medium or large test suite
you can use the looponfailing mode. Simply add the ``--f`` option::
py.test -f
pytest -f
and ``pytest`` will run your tests. Assuming you have failures it will then
wait for file changes and re-run the failing test set. File changes are detected by looking at ``looponfailingroots`` root directories and all of their contents (recursively). If the default for this value does not work for you you
@ -104,7 +104,7 @@ tests that you can successfully run locally. And you also
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
pytest -d --tx ssh=myhostpopen --rsyncdir mypkg mypkg
This will synchronize your ``mypkg`` package directory
with a remote ssh account and then collect and run your
@ -135,7 +135,7 @@ It will tell you that it starts listening on the default
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
pytest -d --tx socket=192.168.1.102:8888 --rsyncdir mypkg mypkg
.. _`atonce`:
@ -145,7 +145,7 @@ 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
pytest --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
@ -174,7 +174,7 @@ You can also add default environments like this::
and then just type::
py.test --dist=each
pytest --dist=each
to run tests in each of the environments.

1
doc/en/yieldfixture.rst
View File

@ -14,4 +14,3 @@
Marking functions as ``yield_fixture`` is still supported, but deprecated and should not
be used in new code.

14
plugin-test.sh
View File

@ -4,17 +4,17 @@
set -e
cd ../pytest-pep8
py.test
pytest
cd ../pytest-instafail
py.test
pytest
cd ../pytest-cache
py.test
pytest
cd ../pytest-xprocess
py.test
pytest
#cd ../pytest-cov
#py.test
#pytest
cd ../pytest-capturelog
py.test
pytest
cd ../pytest-xdist
py.test
pytest

1
setup.py
View File

@ -91,6 +91,7 @@ def cmdline_entrypoints(versioninfo, platform, basename):
else: # cpython
points = {'py.test-%s.%s' % versioninfo[:2] : target}
points['py.test'] = target
points['pytest'] = target
return points

2
testing/cx_freeze/runtests_script.py
View File

@ -1,6 +1,6 @@
"""
This is the script that is actually frozen into an executable: simply executes
py.test main().
pytest main().
"""
if __name__ == '__main__':

2
testing/cx_freeze/runtests_setup.py
View File

@ -8,7 +8,7 @@ if __name__ == '__main__':
setup(
name="runtests",
version="0.1",
description="exemple of how embedding py.test into an executable using cx_freeze",
description="exemple of how embedding pytest into an executable using cx_freeze",
executables=[Executable("runtests_script.py")],
options={"build_exe": {'includes': pytest.freeze_includes()}},
)

2
testing/test_config.py
View File

@ -18,7 +18,7 @@ class TestParseIni:
assert config.inicfg['name'] == 'value'
def test_getcfg_empty_path(self, tmpdir):
getcfg([''], ['setup.cfg']) #happens on py.test ""
getcfg([''], ['setup.cfg']) #happens on pytest ""
def test_append_parse_args(self, testdir, tmpdir, monkeypatch):
monkeypatch.setenv('PYTEST_ADDOPTS', '--color no -rs --tb="short"')

4
testing/test_helpconfig.py
View File

@ -21,8 +21,8 @@ def test_help(testdir):
*-v*verbose*
*setup.cfg*
*minversion*
*to see*markers*py.test --markers*
*to see*fixtures*py.test --fixtures*
*to see*markers*pytest --markers*
*to see*fixtures*pytest --fixtures*
""")
def test_hookvalidation_unknown(testdir):

2
testing/test_junitxml.py
View File

@ -362,7 +362,7 @@ class TestPython:
file="test_collect_skipped.py",
name="test_collect_skipped")
# py.test doesn't give us a line here.
# pytest doesn't give us a line here.
assert tnode["line"] is None
fnode = tnode.find_first_by_tag("skipped")

13
testing/test_parseopt.py
View File

@ -246,8 +246,8 @@ def test_argcomplete(testdir, monkeypatch):
pytest.skip("bash not available")
script = str(testdir.tmpdir.join("test_argcomplete"))
pytest_bin = sys.argv[0]
if "py.test" not in os.path.basename(pytest_bin):
pytest.skip("need to be run with py.test executable, not %s" %(pytest_bin,))
if "pytest" not in os.path.basename(pytest_bin):
pytest.skip("need to be run with pytest executable, not %s" %(pytest_bin,))
with open(str(script), 'w') as fp:
# redirect output from argcomplete to stdin and stderr is not trivial
@ -262,8 +262,8 @@ def test_argcomplete(testdir, monkeypatch):
monkeypatch.setenv('COMP_WORDBREAKS', ' \\t\\n"\\\'><=;|&(:')
arg = '--fu'
monkeypatch.setenv('COMP_LINE', "py.test " + arg)
monkeypatch.setenv('COMP_POINT', str(len("py.test " + arg)))
monkeypatch.setenv('COMP_LINE', "pytest " + arg)
monkeypatch.setenv('COMP_POINT', str(len("pytest " + arg)))
result = testdir.run('bash', str(script), arg)
if result.ret == 255:
# argcomplete not found
@ -280,8 +280,7 @@ def test_argcomplete(testdir, monkeypatch):
return
os.mkdir('test_argcomplete.d')
arg = 'test_argc'
monkeypatch.setenv('COMP_LINE', "py.test " + arg)
monkeypatch.setenv('COMP_POINT', str(len('py.test ' + arg)))
monkeypatch.setenv('COMP_LINE', "pytest " + arg)
monkeypatch.setenv('COMP_POINT', str(len('pytest ' + arg)))
result = testdir.run('bash', str(script), arg)
result.stdout.fnmatch_lines(["test_argcomplete", "test_argcomplete.d/"])

26
tox.ini
View File

@ -7,7 +7,7 @@ envlist=
py27-nobyte,doctesting,py27-cxfreeze
[testenv]
commands= py.test --lsof -rfsxX {posargs:testing}
commands= pytest --lsof -rfsxX {posargs:testing}
passenv = USER USERNAME
deps=
hypothesis
@ -16,7 +16,7 @@ deps=
requests
[testenv:py26]
commands= py.test --lsof -rfsxX {posargs:testing}
commands= pytest --lsof -rfsxX {posargs:testing}
# pinning mock to last supported version for python 2.6
deps=
hypothesis<3.0
@ -30,10 +30,10 @@ deps=pytest-xdist>=1.13
mock
nose
commands=
py.test -n3 -rfsxX --runpytest=subprocess {posargs:testing}
pytest -n3 -rfsxX --runpytest=subprocess {posargs:testing}
[testenv:genscript]
commands= py.test --genscript=pytest1
commands= pytest --genscript=pytest1
[testenv:linting]
basepython = python2.7
@ -48,26 +48,26 @@ deps=pytest-xdist>=1.13
nose
hypothesis
commands=
py.test -n1 -rfsxX {posargs:testing}
pytest -n1 -rfsxX {posargs:testing}
[testenv:py35-xdist]
deps={[testenv:py27-xdist]deps}
commands=
py.test -n3 -rfsxX {posargs:testing}
pytest -n3 -rfsxX {posargs:testing}
[testenv:py27-pexpect]
changedir=testing
platform=linux|darwin
deps=pexpect
commands=
py.test -rfsxX test_pdb.py test_terminal.py test_unittest.py
pytest -rfsxX test_pdb.py test_terminal.py test_unittest.py
[testenv:py35-pexpect]
changedir=testing
platform=linux|darwin
deps={[testenv:py27-pexpect]deps}
commands=
py.test -rfsxX test_pdb.py test_terminal.py test_unittest.py
pytest -rfsxX test_pdb.py test_terminal.py test_unittest.py
[testenv:py27-nobyte]
deps=pytest-xdist>=1.13
@ -76,21 +76,21 @@ distribute=true
setenv=
PYTHONDONTWRITEBYTECODE=1
commands=
py.test -n3 -rfsxX {posargs:testing}
pytest -n3 -rfsxX {posargs:testing}
[testenv:py27-trial]
deps=twisted
commands=
py.test -rsxf {posargs:testing/test_unittest.py}
pytest -rsxf {posargs:testing/test_unittest.py}
[testenv:py35-trial]
platform=linux|darwin
deps={[testenv:py27-trial]deps}
commands=
py.test -rsxf {posargs:testing/test_unittest.py}
pytest -rsxf {posargs:testing/test_unittest.py}
[testenv:doctest]
commands=py.test --doctest-modules _pytest
commands=pytest --doctest-modules _pytest
deps=
[testenv:doc]
@ -107,7 +107,7 @@ commands=
basepython = python
changedir=doc/en
deps=PyYAML
commands= py.test -rfsxX {posargs}
commands= pytest -rfsxX {posargs}
[testenv:regen]
changedir=doc/en