Use pytest instead of py.test per upstream recommendation, #dropthedot

http://blog.pytest.org/2016/whats-new-in-pytest-30/
https://twitter.com/hashtag/dropthedot

ISSUES.txt

@@ -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

README.rst

@@ -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.
 

example/boxed.txt

@@ -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

example/loadscope/tox.ini

@@ -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 \

setup.py

@@ -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',

tox.ini

@@ -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=

xdist/dsession.py

@@ -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.
     """

xdist/looponfail.py

@@ -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

xdist/workermanage.py

@@ -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: