diff --git a/.github/ISSUE_TEMPLATE.md b/.github/ISSUE_TEMPLATE.md index bc62e8a3f7d..fbcbb16fc35 100644 --- a/.github/ISSUE_TEMPLATE.md +++ b/.github/ISSUE_TEMPLATE.md @@ -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 diff --git a/README.rst b/README.rst index 68fc92211d8..3c658ee93fc 100644 --- a/README.rst +++ b/README.rst @@ -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 `_ for more examples. +Due to ``pytest``'s detailed assertion introspection, only plain ``assert`` statements are used. See `getting-started `_ for more examples. Features diff --git a/_pytest/capture.py b/_pytest/capture.py index 78401e96d33..48c14fbc8da 100644 --- a/_pytest/capture.py +++ b/_pytest/capture.py @@ -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 diff --git a/_pytest/genscript.py b/_pytest/genscript.py index d2962d8fc82..62139add983 100755 --- a/_pytest/genscript.py +++ b/_pytest/genscript.py @@ -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)) diff --git a/_pytest/helpconfig.py b/_pytest/helpconfig.py index 1df0c56ac7b..15b0ada77c6 100644 --- a/_pytest/helpconfig.py +++ b/_pytest/helpconfig.py @@ -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)") diff --git a/_pytest/hookspec.py b/_pytest/hookspec.py index 424ee20696b..639e316d0c7 100644 --- a/_pytest/hookspec.py +++ b/_pytest/hookspec.py @@ -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 `. :arg parser: To add command line options, call diff --git a/_pytest/pytester.py b/_pytest/pytester.py index faed7f581c9..83b87e741f4 100644 --- a/_pytest/pytester.py +++ b/_pytest/pytester.py @@ -374,10 +374,10 @@ def assert_outcomes(self, passed=0, skipped=0, failed=0): 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 @@ def getpathnode(self, path): """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 @@ def inline_genitems(self, *args): :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 @@ def inline_run(self, *args, **kwargs): """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 @@ def _ensure_basetemp(self, args): 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 @@ def parseconfig(self, *args): 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 @@ def parseconfigure(self, *args): 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 @@ def getitem(self, source, funcname="test_func"): 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 @@ def getmodulecol(self, source, configargs=(), withinit=False): """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 @@ def _dump_lines(self, lines, fp): 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 @@ def runpython_c(self, command): 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 @@ def runpytest_subprocess(self, *args, **kwargs): 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. diff --git a/_pytest/python.py b/_pytest/python.py index 526f4be09cb..a285666db93 100644 --- a/_pytest/python.py +++ b/_pytest/python.py @@ -2173,7 +2173,7 @@ def formatrepr(self): 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) diff --git a/_pytest/standalonetemplate.py b/_pytest/standalonetemplate.py index 484d5d1b25f..50799b0dd8e 100755 --- a/_pytest/standalonetemplate.py +++ b/_pytest/standalonetemplate.py @@ -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@""" diff --git a/doc/en/assert.rst b/doc/en/assert.rst index d867dfa9af6..03bcc8a3d36 100644 --- a/doc/en/assert.rst +++ b/doc/en/assert.rst @@ -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 ________ diff --git a/doc/en/bash-completion.rst b/doc/en/bash-completion.rst index b820944bfeb..81fe62183fb 100644 --- a/doc/en/bash-completion.rst +++ b/doc/en/bash-completion.rst @@ -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)" diff --git a/doc/en/builtin.rst b/doc/en/builtin.rst index d364dd56d54..898dc495a65 100644 --- a/doc/en/builtin.rst +++ b/doc/en/builtin.rst @@ -77,7 +77,7 @@ Builtin fixtures/function arguments You can ask for available builtin or project-custom :ref:`fixtures ` by typing:: - $ py.test -q --fixtures + $ pytest -q --fixtures cache Return a cache object that can persist state between testing sessions. diff --git a/doc/en/cache.rst b/doc/en/cache.rst index de03204def5..8cfe50d9073 100644 --- a/doc/en/cache.rst +++ b/doc/en/cache.rst @@ -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 diff --git a/doc/en/capture.rst b/doc/en/capture.rst index f4692071234..0004f5b18a1 100644 --- a/doc/en/capture.rst +++ b/doc/en/capture.rst @@ -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: diff --git a/doc/en/customize.rst b/doc/en/customize.rst index 69cf7c24110..aa2f4af43b8 100644 --- a/doc/en/customize.rst +++ b/doc/en/customize.rst @@ -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 `. + :doc:`See how pytest handles doctests `. .. confval:: confcutdir diff --git a/doc/en/doctest.rst b/doc/en/doctest.rst index 927c2be8cc3..80f5c9506ba 100644 --- a/doc/en/doctest.rst +++ b/doc/en/doctest.rst @@ -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 diff --git a/doc/en/example/markers.rst b/doc/en/example/markers.rst index ccca811bc64..1d26e01a862 100644 --- a/doc/en/example/markers.rst +++ b/doc/en/example/markers.rst @@ -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 ` 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: diff --git a/doc/en/example/nonpython.rst b/doc/en/example/nonpython.rst index b7daa75f367..9ecf0e45152 100644 --- a/doc/en/example/nonpython.rst +++ b/doc/en/example/nonpython.rst @@ -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: diff --git a/doc/en/example/parametrize.rst b/doc/en/example/parametrize.rst index ef5b3535c5a..66fe713823a 100644 --- a/doc/en/example/parametrize.rst +++ b/doc/en/example/parametrize.rst @@ -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: diff --git a/doc/en/example/pythoncollection.py b/doc/en/example/pythoncollection.py index 05858eb854b..0b9e35df484 100644 --- a/doc/en/example/pythoncollection.py +++ b/doc/en/example/pythoncollection.py @@ -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 diff --git a/doc/en/example/pythoncollection.rst b/doc/en/example/pythoncollection.rst index bd637299fde..e475eee250e 100644 --- a/doc/en/example/pythoncollection.rst +++ b/doc/en/example/pythoncollection.rst @@ -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 diff --git a/doc/en/example/reportingdemo.rst b/doc/en/example/reportingdemo.rst index 917eeeae674..2afc853f3d3 100644 --- a/doc/en/example/reportingdemo.rst +++ b/doc/en/example/reportingdemo.rst @@ -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: diff --git a/doc/en/example/simple.rst b/doc/en/example/simple.rst index cbb46e81abb..7bad0315a50 100644 --- a/doc/en/example/simple.rst +++ b/doc/en/example/simple.rst @@ -37,7 +37,7 @@ provide the ``cmdopt`` through a :ref:`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/ diff --git a/doc/en/example/special.rst b/doc/en/example/special.rst index 58e66d44e34..fdffef089a0 100644 --- a/doc/en/example/special.rst +++ b/doc/en/example/special.rst @@ -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 diff --git a/doc/en/faq.rst b/doc/en/faq.rst index fd7ca35e943..774998b1433 100644 --- a/doc/en/faq.rst +++ b/doc/en/faq.rst @@ -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? -++++++++++++++++++++++++++++++++++++++++++++++++++ - -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.``, 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. +Why can I use both ``pytest`` and ``py.test`` commands? ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + +pytest used to be part of the py package, which provided several developer +utilities, all starting with ``py.``, 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 ------------------------------------------------------- diff --git a/doc/en/fixture.rst b/doc/en/fixture.rst index dd2c1f96cbc..b40c3943ad9 100644 --- a/doc/en/fixture.rst +++ b/doc/en/fixture.rst @@ -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 (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 diff --git a/doc/en/funcarg_compare.rst b/doc/en/funcarg_compare.rst index 832922e1839..d8122a5d2cd 100644 --- a/doc/en/funcarg_compare.rst +++ b/doc/en/funcarg_compare.rst @@ -172,17 +172,17 @@ to do this with parametrization as ``pytest_runtest_setup()`` is called during test execution and parametrization happens at collection time. It follows that pytest_configure/session/runtest_setup are often not -appropriate for implementing common fixture needs. Therefore, +appropriate for implementing common fixture needs. Therefore, pytest-2.3 introduces :ref:`autouse fixtures` which fully -integrate with the generic :ref:`fixture mechanism ` +integrate with the generic :ref:`fixture mechanism ` 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 -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 +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 "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. diff --git a/doc/en/getting-started.rst b/doc/en/getting-started.rst index 0372f7f3b02..5455d4a5dfc 100644 --- a/doc/en/getting-started.rst +++ b/doc/en/getting-started.rst @@ -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 diff --git a/doc/en/goodpractices.rst b/doc/en/goodpractices.rst index 89396b57ed8..2cd96ea311e 100644 --- a/doc/en/goodpractices.rst +++ b/doc/en/goodpractices.rst @@ -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. diff --git a/doc/en/nose.rst b/doc/en/nose.rst index 04386ea0f5b..ffad1f4d380 100644 --- a/doc/en/nose.rst +++ b/doc/en/nose.rst @@ -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. diff --git a/doc/en/parametrize.rst b/doc/en/parametrize.rst index 7d496ed7071..40b9dad14b9 100644 --- a/doc/en/parametrize.rst +++ b/doc/en/parametrize.rst @@ -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 diff --git a/doc/en/plugins.rst b/doc/en/plugins.rst index 3db7f0f5940..0d5ca7e05d1 100644 --- a/doc/en/plugins.rst +++ b/doc/en/plugins.rst @@ -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 `_. 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. diff --git a/doc/en/skipping.rst b/doc/en/skipping.rst index 61764d71dbd..da1b0e9c8f6 100644 --- a/doc/en/skipping.rst +++ b/doc/en/skipping.rst @@ -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. diff --git a/doc/en/test/attic.rst b/doc/en/test/attic.rst index 2ab9c237aef..11140db2c0b 100644 --- a/doc/en/test/attic.rst +++ b/doc/en/test/attic.rst @@ -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 diff --git a/doc/en/test/mission.rst b/doc/en/test/mission.rst index cda8d9a7208..51c252dc0d8 100644 --- a/doc/en/test/mission.rst +++ b/doc/en/test/mission.rst @@ -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 diff --git a/doc/en/test/plugin/cov.rst b/doc/en/test/plugin/cov.rst index 355093f2586..541c7ef9479 100644 --- a/doc/en/test/plugin/cov.rst +++ b/doc/en/test/plugin/cov.rst @@ -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 diff --git a/doc/en/test/plugin/coverage.rst b/doc/en/test/plugin/coverage.rst index 965b4a4ee07..71139d008ba 100644 --- a/doc/en/test/plugin/coverage.rst +++ b/doc/en/test/plugin/coverage.rst @@ -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 -------------------- diff --git a/doc/en/test/plugin/figleaf.rst b/doc/en/test/plugin/figleaf.rst index 86e0da65b6b..0c1603ade9f 100644 --- a/doc/en/test/plugin/figleaf.rst +++ b/doc/en/test/plugin/figleaf.rst @@ -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 diff --git a/doc/en/test/plugin/nose.rst b/doc/en/test/plugin/nose.rst index f3aa7d705f5..9eeae5ff697 100644 --- a/doc/en/test/plugin/nose.rst +++ b/doc/en/test/plugin/nose.rst @@ -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. diff --git a/doc/en/test/plugin/xdist.rst b/doc/en/test/plugin/xdist.rst index 7ab6cdc8b83..79440998bfd 100644 --- a/doc/en/test/plugin/xdist.rst +++ b/doc/en/test/plugin/xdist.rst @@ -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 diff --git a/doc/en/tmpdir.rst b/doc/en/tmpdir.rst index 4242adf8231..cbad3a52e07 100644 --- a/doc/en/tmpdir.rst +++ b/doc/en/tmpdir.rst @@ -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 diff --git a/doc/en/unittest.rst b/doc/en/unittest.rst index 69e8ce52d23..5245a0a7a9a 100644 --- a/doc/en/unittest.rst +++ b/doc/en/unittest.rst @@ -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 diff --git a/doc/en/usage.rst b/doc/en/usage.rst index f9add12ab78..06cc1896933 100644 --- a/doc/en/usage.rst +++ b/doc/en/usage.rst @@ -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:: diff --git a/doc/en/writing_plugins.rst b/doc/en/writing_plugins.rst index 7e7b73330e6..aeb30724cf2 100644 --- a/doc/en/writing_plugins.rst +++ b/doc/en/writing_plugins.rst @@ -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 diff --git a/doc/en/xdist.rst b/doc/en/xdist.rst index ee1bd603283..fa662b7d3cf 100644 --- a/doc/en/xdist.rst +++ b/doc/en/xdist.rst @@ -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. diff --git a/doc/en/yieldfixture.rst b/doc/en/yieldfixture.rst index 2b77a6297c4..b372973e5ab 100644 --- a/doc/en/yieldfixture.rst +++ b/doc/en/yieldfixture.rst @@ -14,4 +14,3 @@ Marking functions as ``yield_fixture`` is still supported, but deprecated and should not be used in new code. - diff --git a/plugin-test.sh b/plugin-test.sh index 9c61b50536e..7830b7c7d16 100644 --- a/plugin-test.sh +++ b/plugin-test.sh @@ -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 diff --git a/setup.py b/setup.py index 7cdcdfb9927..6966fe1f234 100644 --- a/setup.py +++ b/setup.py @@ -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 diff --git a/testing/cx_freeze/runtests_script.py b/testing/cx_freeze/runtests_script.py index f2b032d7655..d4a974a9f47 100644 --- a/testing/cx_freeze/runtests_script.py +++ b/testing/cx_freeze/runtests_script.py @@ -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__': diff --git a/testing/cx_freeze/runtests_setup.py b/testing/cx_freeze/runtests_setup.py index a2874a655eb..ee11d885486 100644 --- a/testing/cx_freeze/runtests_setup.py +++ b/testing/cx_freeze/runtests_setup.py @@ -8,7 +8,7 @@ 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()}}, ) diff --git a/testing/test_config.py b/testing/test_config.py index fe06540173e..173db3aabbd 100644 --- a/testing/test_config.py +++ b/testing/test_config.py @@ -18,7 +18,7 @@ def test_getcfg_and_config(self, testdir, tmpdir): 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"') diff --git a/testing/test_helpconfig.py b/testing/test_helpconfig.py index 9f8d87b7cb5..fc3c8fdf69e 100644 --- a/testing/test_helpconfig.py +++ b/testing/test_helpconfig.py @@ -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): diff --git a/testing/test_junitxml.py b/testing/test_junitxml.py index 0b00c3a7042..fde003e315b 100644 --- a/testing/test_junitxml.py +++ b/testing/test_junitxml.py @@ -362,7 +362,7 @@ def test_collect_skipped(self, testdir): 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") diff --git a/testing/test_parseopt.py b/testing/test_parseopt.py index e45ee285409..4b86677182e 100644 --- a/testing/test_parseopt.py +++ b/testing/test_parseopt.py @@ -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/"]) - diff --git a/tox.ini b/tox.ini index ee9dd102ef0..957849559c7 100644 --- a/tox.ini +++ b/tox.ini @@ -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