Merge pull request #308 from scop/dropthedot

Use pytest instead of py.test per upstream recommendation, #dropthedot
This commit is contained in:
Bruno Oliveira
2018-07-06 22:20:53 -03:00
committed by GitHub
9 changed files with 21 additions and 21 deletions

View File

@@ -19,7 +19,7 @@ tag: feature
allow to run xdist own tests using its own mechanism.
currently this doesn't work because the remote side
has no py.test plugin. How to configure/do
has no pytest plugin. How to configure/do
register "xdist.plugin" on the remote side?
see to avoid any "from _pytest" internal imports

View File

@@ -23,7 +23,7 @@
xdist: pytest distributed testing plugin
========================================
The `pytest-xdist`_ plugin extends py.test with some unique
The `pytest-xdist`_ plugin extends pytest with some unique
test execution modes:
* test run parallelization_: if you have multiple CPUs or hosts you can use
@@ -32,14 +32,14 @@ test execution modes:
* ``--looponfail``: run your tests repeatedly in a subprocess. After each run
py.test waits until a file in your project changes and then re-runs
pytest waits until a file in your project changes and then re-runs
the previously failing tests. This is repeated until all tests pass
after which again a full run is performed.
* `Multi-Platform`_ coverage: you can specify different Python interpreters
or different platforms and run tests in parallel on all of them.
Before running tests remotely, ``py.test`` efficiently "rsyncs" your
Before running tests remotely, ``pytest`` efficiently "rsyncs" your
program source code to the remote place. All test results
are reported back and displayed to your local terminal.
You may specify different Python versions and interpreters.
@@ -67,7 +67,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. This option can
@@ -98,7 +98,7 @@ Running tests in a Python subprocess
To instantiate a python3.5 subprocess and send tests to it, you may type::
py.test -d --tx popen//python=python3.5
pytest -d --tx popen//python=python3.5
This will start a subprocess which is run with the ``python3.5``
Python interpreter, found in your system binary lookup path.
@@ -129,7 +129,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 :code:`mypkg` package directory
to a remote ssh account and then locally collect tests
@@ -140,11 +140,11 @@ to be sent to the remote side.
.. note::
For py.test to collect and send tests correctly
For pytest to collect and send tests correctly
you not only need to make sure all code and tests
directories are rsynced, but that any test (sub) directory
also has an :code:`__init__.py` file because internally
py.test references tests as a fully qualified python
pytest references tests as a fully qualified python
module path. **You will otherwise get strange errors**
during setup of the remote side.
@@ -168,7 +168,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`:
@@ -180,7 +180,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
@@ -242,7 +242,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.

View File

@@ -25,7 +25,7 @@ to run each test in a controlled subprocess. Here is a basic example::
If you run this with::
$ py.test -n1
$ pytest -n1
=========================== test session starts ============================
platform linux2 -- Python 2.7.3 -- pytest-2.3.0.dev8
plugins: xdist, bugzilla, cache, oejskit, cli, pep8, cov
@@ -46,7 +46,7 @@ You'll see that a couple of tests are reported as crashing, indicated
by lower-case ``f`` and the respective failure summary. You can also use
the xdist-provided parallelization feature to speed up your testing::
$ py.test -n3
$ pytest -n3
=========================== test session starts ============================
platform linux2 -- Python 2.7.3 -- pytest-2.3.0.dev8
plugins: xdist, bugzilla, cache, oejskit, cli, pep8, cov

View File

@@ -8,7 +8,7 @@ passenv = http_proxy https_proxy
deps = -rrequirements.txt
changedir = {envtmpdir}
commands =
py.test -s -v \
pytest -s -v \
--doctest-modules \
--junitxml=tests.xml \
--dist=loadscope \

View File

@@ -6,7 +6,7 @@ install_requires = ['execnet>=1.1', 'pytest>=3.0.0', 'pytest-forked']
setup(
name="pytest-xdist",
use_scm_version={'write_to': 'xdist/_version.py'},
description='py.test xdist plugin for distributed testing'
description='pytest xdist plugin for distributed testing'
' and loop-on-failing modes',
long_description=open('README.rst').read(),
license='MIT',

View File

@@ -27,7 +27,7 @@ platform=
commands=
# always clean to avoid code unmarshal mismatch on old python/pytest
py.cleanup -aq
py.test {posargs}
pytest {posargs}
[testenv:flakes]
changedir=

View File

@@ -18,7 +18,7 @@ class Interrupted(KeyboardInterrupt):
class DSession(object):
"""A py.test plugin which runs a distributed test session
"""A pytest plugin which runs a distributed test session
At the beginning of the test session this creates a NodeManager
instance which creates and starts all nodes. Nodes then emit
@@ -26,7 +26,7 @@ class DSession(object):
methods.
Once a node is started it will automatically start running the
py.test mainloop with some custom hooks. This means a node
pytest mainloop with some custom hooks. This means a node
automatically starts collecting tests. Once tests are collected
it will wait for instructions.
"""

View File

@@ -1,5 +1,5 @@
"""
Implement -f aka looponfailing for py.test.
Implement -f aka looponfailing for pytest.
NOTE that we try to avoid loading and depending on application modules
within the controlling process (the one that starts repeatedly test

View File

@@ -184,7 +184,7 @@ class HostRSync(execnet.RSync):
def make_reltoroot(roots, args):
# XXX introduce/use public API for splitting py.test args
# XXX introduce/use public API for splitting pytest args
splitcode = "::"
result = []
for arg in args: