Rename py.test to pytest

Change-Id: I431e1ef41e26d490343204a75a5c097768749768
(cherry picked from commit 405fc9717048b0adc852a72da540048df7a8142a)

diff --git a/README.dialects.rst b/README.dialects.rst
index 7335c0f0eaf467129c50d1fc11495599d61341c3..f5a15c8be5bb61a8d9a7342fb38c0d7001d740ba 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 74c652046edcb4f485f34f6a69296cf5e35fb0cf..ed66ce5648ca35e8d0f43af724144f28625282fe 100644 (file)
--- a/README.unittests.rst
+++ b/README.unittests.rst
@@ -36,43 +36,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
 ==================
 
-Both the tox runner and the setup.py runner are 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 SQLAlchemy's multiple database support,
-database setup/teardown and connectivity, multi process support, as well as
-lots of skip / database selection rules.
+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 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::
+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 +82,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
@@ -109,7 +110,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::
@@ -125,14 +126,16 @@ Database Configuration
 ======================
 
 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
-multiprocessing option is **enabled by default** for both the tox runner
-and the setup.py frontend.   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 complete.    So it will be necessary
-for the database user to have access to CREATE DATABASE in order for this
-to work.
+database that's in the database URL, *unless* the multiprocessing option is in
+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
+complete.    So it will be necessary for the database user to have access to
+CREATE DATABASE in order for this to work.   Additionally, as mentioned
+earlier, the database URL must be formatted such that it can be rewritten on
+the fly to refer to these other databases, which means for pyodbc it must refer
+to a hostname/database name combination, not a DSN name.
 
 Several tests require alternate usernames or schemas to be present, which
 are used to test dotted-name access scenarios.  On some databases such
@@ -203,10 +206,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 e5e6c42fc0f0e7b66b9c86f6160868f73b04bf8a..98d6b2b868cd8ccd6852a9987375973672d72576 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 2955a05063d08e989d0cf849bc560097acea016b..2b062cee4a2736900221bc67fc6624a73dc2d349 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.
 
 """
 
@@ -199,7 +199,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 2c2cc398e80d440a5bd48ddb8651319b990049fb..6fa93189ccd39fc4a11405248f7f0c6057a9013b 100644 (file)
--- a/lib/sqlalchemy/testing/plugin/pytestplugin.py
+++ b/lib/sqlalchemy/testing/plugin/pytestplugin.py
@@ -245,7 +245,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
@@ -289,7 +289,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/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 b8322db0a9553b17f6ec3261f4e24cca65a33f57..07444f12411f15cbcedf8d4d8c4c7d78fee38b27 100644 (file)
--- a/test/base/test_tutorials.py
+++ b/test/base/test_tutorials.py
@@ -90,7 +90,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 cdabc9785087e41bfb6ef66c4f9ee032b6f64ec8..bd809345b9c7c4b7f30a060b6d4b54b106da64ae 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.
 
 """
@@ -12,7 +12,7 @@ import sys
 
 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.