Rename py.test to pytest

Change-Id: I431e1ef41e26d490343204a75a5c097768749768

diff --git a/README.dialects.rst b/README.dialects.rst
index b300128bb224ea3338c92ba128bad93eab1b62fb..e4bf7f2d22fd6cf2bfe12eacba90f0589cb930ed 100644 (file)
--- a/README.dialects.rst
+++ b/README.dialects.rst
@@ -6,7 +6,7 @@ Developing new Dialects
 
    When studying this file, it's probably a good idea to also
    familiarize with the  README.unittests.rst file, which discusses
-   SQLAlchemy's usage and extension of the py.test test runner.
+   SQLAlchemy's usage and extension of the pytest test runner.
 
 While SQLAlchemy includes many dialects within the core distribution, the
 trend for new dialects should be that they are published as external
@@ -154,7 +154,7 @@ Key aspects of this file layout include:
   test runner so that exclusions specific to the dialect take place::
 
     cd /path/to/sqlalchemy
-    py.test -v \
+    pytest -v \
       --requirements sqlalchemy_access.requirements:Requirements \
       --dburi access+pyodbc://admin@access_test
 

diff --git a/README.unittests.rst b/README.unittests.rst
index 47ae3c7cd6072d2d8b69b01d56d573db2cfed959..14b1bbcafb7c55631f4a247f44ca782026818f4c 100644 (file)
--- a/README.unittests.rst
+++ b/README.unittests.rst
@@ -35,44 +35,44 @@ Running against backends other than SQLite requires that a database of that
 vendor be available at a specific URL.  See "Setting Up Databases" below
 for details.
 
-The py.test Engine
+The pytest Engine
 ==================
 
-The tox runner is using py.test to invoke the test suite.   Within the realm of
-py.test, SQLAlchemy itself is adding a large series of option and
-customizations to the py.test runner using plugin points, to allow for
+The tox runner is using pytest to invoke the test suite.   Within the realm of
+pytest, SQLAlchemy itself is adding a large series of option and
+customizations to the pytest runner using plugin points, to allow for
 SQLAlchemy's multiple database support, database setup/teardown and
 connectivity, multi process support, as well as lots of skip / database
 selection rules.
 
-Running tests with py.test directly grants more immediate control over
+Running tests with pytest directly grants more immediate control over
 database options and test selection.
 
-A generic py.test run looks like::
+A generic pytest run looks like::
 
-    py.test -n4
+    pytest -n4
 
 Above, the full test suite will run against SQLite, using four processes.
 If the "-n" flag is not used, the pytest-xdist is skipped and the tests will
 run linearly, which will take a pretty long time.
 
-The py.test command line is more handy for running subsets of tests and to
+The pytest command line is more handy for running subsets of tests and to
 quickly allow for custom database connections.  Example::
 
-    py.test --dburi=postgresql+psycopg2://scott:tiger@localhost/test  test/sql/test_query.py
+    pytest --dburi=postgresql+psycopg2://scott:tiger@localhost/test  test/sql/test_query.py
 
 Above will run the tests in the test/sql/test_query.py file (a pretty good
 file for basic "does this database work at all?" to start with) against a
 running PostgreSQL database at the given URL.
 
-The py.test frontend can also run tests against multiple kinds of databases at
+The pytest frontend can also run tests against multiple kinds of databases at
 once - a large subset of tests are marked as "backend" tests, which will be run
 against each available backend, and additionally lots of tests are targeted at
 specific backends only, which only run if a matching backend is made available.
 For example, to run the test suite against both PostgreSQL and MySQL at the
 same time::
 
-    py.test -n4 --db postgresql --db mysql
+    pytest -n4 --db postgresql --db mysql
 
 
 Setting Up Databases
@@ -81,7 +81,7 @@ Setting Up Databases
 The test suite identifies several built-in database tags that run against
 a pre-set URL.  These can be seen using --dbs::
 
-    $ py.test --dbs
+    $ pytest --dbs
     Available --db options (use --dburi to override)
                  default    sqlite:///:memory:
                 firebird    firebird://sysdba:masterkey@localhost//Users/classic/foo.fdb
@@ -114,7 +114,7 @@ creating a new file called ``test.cfg`` and adding your own ``[db]`` section::
 
 Above, we can now run the tests with ``my_postgresql``::
 
-    py.test --db my_postgresql
+    pytest --db my_postgresql
 
 We can also override the existing names in our ``test.cfg`` file, so that we can run
 with the tox runner also::
@@ -145,7 +145,7 @@ configurations using docker.
 
 The test runner will by default create and drop tables within the default
 database that's in the database URL, *unless* the multiprocessing option is in
-use via the py.test "-n" flag, which invokes pytest-xdist.   The
+use via the pytest "-n" flag, which invokes pytest-xdist.   The
 multiprocessing option is **enabled by default** when using the tox runner.
 When multiprocessing is used, the SQLAlchemy testing framework will create a
 new database for each process, and then tear it down after the test run is
@@ -281,7 +281,7 @@ intended for production use!
 
 NOTE: with this configuration the url to use is not the default one configured
 in setup, but ``mssql+pymssql://scott:tiger^5HHH@127.0.0.1:1433/test``.  It can
-be used with py.test by using ``--db docker_mssql``.
+be used with pytest by using ``--db docker_mssql``.
 
 CONFIGURING LOGGING
 -------------------
@@ -289,10 +289,10 @@ SQLAlchemy logs its activity and debugging through Python's logging package.
 Any log target can be directed to the console with command line options, such
 as::
 
-    $ ./py.test test/orm/test_unitofwork.py -s \
+    $ ./pytest test/orm/test_unitofwork.py -s \
       --log-debug=sqlalchemy.pool --log-info=sqlalchemy.engine
 
-Above we add the py.test "-s" flag so that standard out is not suppressed.
+Above we add the pytest "-s" flag so that standard out is not suppressed.
 
 
 DEVELOPING AND TESTING NEW DIALECTS

diff --git a/examples/versioned_history/__init__.py b/examples/versioned_history/__init__.py
index 3deb7fcb2f7cf9e55d64c94a1cc232729630c4db..53c9c498e1fa56a9ccae1728fb841ba5ca3aa866 100644 (file)
--- a/examples/versioned_history/__init__.py
+++ b/examples/versioned_history/__init__.py
@@ -7,12 +7,12 @@ Compare to the :ref:`examples_versioned_rows` examples which write updates
 as new rows in the same table, without using a separate history table.
 
 Usage is illustrated via a unit test module ``test_versioning.py``, which can
-be run via ``py.test``::
+be run via ``pytest``::
 
-    # assume SQLAlchemy is installed where py.test is
+    # assume SQLAlchemy is installed where pytest is
 
     cd examples/versioned_history
-    py.test test_versioning.py
+    pytest test_versioning.py
 
 
 A fragment of example usage, using declarative::

diff --git a/lib/sqlalchemy/testing/fixtures.py b/lib/sqlalchemy/testing/fixtures.py
index 26ae221b89a5d82eca14bbeadc4e83bf25f5ef8d..a4399830e9e8e1630bf4553b158bc3b7ea6b1924 100644 (file)
--- a/lib/sqlalchemy/testing/fixtures.py
+++ b/lib/sqlalchemy/testing/fixtures.py
@@ -23,7 +23,7 @@ from ..ext.declarative import DeclarativeMeta
 
 
 # whether or not we use unittest changes things dramatically,
-# as far as how py.test collection works.
+# as far as how pytest collection works.
 
 
 class TestBase(object):

diff --git a/lib/sqlalchemy/testing/plugin/plugin_base.py b/lib/sqlalchemy/testing/plugin/plugin_base.py
index 29dab098aef01bb816d1949a0e37c00ec5db4a8c..9b2f6911da85a482e498da7cb6c1989b095d9b1b 100644 (file)
--- a/lib/sqlalchemy/testing/plugin/plugin_base.py
+++ b/lib/sqlalchemy/testing/plugin/plugin_base.py
@@ -10,7 +10,7 @@
 this module is designed to work as a testing-framework-agnostic library,
 created so that multiple test frameworks can be supported at once
 (mostly so that we can migrate to new ones). The current target
-is py.test.
+is pytest.
 
 """
 
@@ -206,7 +206,7 @@ def memoize_important_follower_config(dict_):
 
     This invokes in the parent process after normal config is set up.
 
-    This is necessary as py.test seems to not be using forking, so we
+    This is necessary as pytest seems to not be using forking, so we
     start with nothing in memory, *but* it isn't running our argparse
     callables, so we have to just copy all of that over.
 

diff --git a/lib/sqlalchemy/testing/plugin/pytestplugin.py b/lib/sqlalchemy/testing/plugin/pytestplugin.py
index f2e7d706f6c37756b3b14d88192dab3c07585418..9dc40c9fefba20c11a0f5efdaa9d96c8c6918dcf 100644 (file)
--- a/lib/sqlalchemy/testing/plugin/pytestplugin.py
+++ b/lib/sqlalchemy/testing/plugin/pytestplugin.py
@@ -243,7 +243,7 @@ def _parametrize_cls(module, cls):
             for arg, val in zip(argname_split, param.values):
                 cls_variables[arg] = val
         parametrized_name = "_".join(
-            # token is a string, but in py2k py.test is giving us a unicode,
+            # token is a string, but in py2k pytest is giving us a unicode,
             # so call str() on it.
             str(re.sub(r"\W", "", token))
             for param in full_param_set
@@ -287,7 +287,7 @@ def pytest_runtest_teardown(item):
     # ...but this works better as the hook here rather than
     # using a finalizer, as the finalizer seems to get in the way
     # of the test reporting failures correctly (you get a bunch of
-    # py.test assertion stuff instead)
+    # pytest assertion stuff instead)
     test_teardown(item)
 
 

diff --git a/lib/sqlalchemy/testing/profiling.py b/lib/sqlalchemy/testing/profiling.py
index b6108400d25b7c545d923c6bd5eda9dd60e1b64d..24e96dfab41661324a43dd9947f36f5865f4a80b 100644 (file)
--- a/lib/sqlalchemy/testing/profiling.py
+++ b/lib/sqlalchemy/testing/profiling.py
@@ -236,7 +236,7 @@ def function_call_count(variance=0.05, times=1, warmup=0):
 
     """
 
-    # use signature-rewriting decorator function so that py.test fixtures
+    # use signature-rewriting decorator function so that pytest fixtures
     # still work on py27.  In Py3, update_wrapper() alone is good enough,
     # likely due to the introduction of __signature__.
 

diff --git a/lib/sqlalchemy/testing/provision.py b/lib/sqlalchemy/testing/provision.py
index 0123ea7e7aa93972496293beba314f0ca22833d9..660a3bd24c16b24398924b58e9327764e56e5c98 100644 (file)
--- a/lib/sqlalchemy/testing/provision.py
+++ b/lib/sqlalchemy/testing/provision.py
@@ -97,7 +97,7 @@ def create_db(cfg, eng, ident):
     """Dynamically create a database for testing.
 
     Used when a test run will employ multiple processes, e.g., when run
-    via `tox` or `py.test -n4`.
+    via `tox` or `pytest -n4`.
     """
     raise NotImplementedError("no DB creation routine for cfg: %s" % eng.url)
 

diff --git a/test/base/test_tutorials.py b/test/base/test_tutorials.py
index 97dca753de75a20c9989024d01ed5ae3708ccec3..4b8de298b48291b8eb416c753297b1478dfcbca9 100644 (file)
--- a/test/base/test_tutorials.py
+++ b/test/base/test_tutorials.py
@@ -92,7 +92,7 @@ class DocTest(fixtures.TestBase):
         self._run_doctest("core/tutorial.rst")
 
 
-# unicode checker courtesy py.test
+# unicode checker courtesy pytest
 
 
 def _get_unicode_checker():

diff --git a/test/conftest.py b/test/conftest.py
index 6f7fe460d3e91d0cb0204b86a676fc2217779908..5c6b89fde7ce98eabdc63843ac0d8b599c9aa7bc 100755 (executable)
--- a/test/conftest.py
+++ b/test/conftest.py
@@ -2,7 +2,7 @@
 """
 pytest plugin script.
 
-This script is an extension to py.test which
+This script is an extension to pytest which
 installs SQLAlchemy's testing plugin into the local environment.
 
 """
@@ -16,7 +16,7 @@ pytest.register_assert_rewrite("sqlalchemy.testing.assertions")
 
 if not sys.flags.no_user_site:
     # this is needed so that test scenarios like "python setup.py test"
-    # work correctly, as well as plain "py.test".  These commands assume
+    # work correctly, as well as plain "pytest".  These commands assume
     # that the package in question is locally present, but since we have
     # ./lib/, we need to punch that in.
     # We check no_user_site to honor the use of this flag.