From 40f07675e3d00700fb41205346fe4fb3752ec845 Mon Sep 17 00:00:00 2001 From: Gord Thompson Date: Thu, 16 Apr 2020 16:06:36 -0600 Subject: [PATCH] Rename py.test to pytest Change-Id: I431e1ef41e26d490343204a75a5c097768749768 (cherry picked from commit 405fc9717048b0adc852a72da540048df7a8142a) --- README.dialects.rst | 4 +- README.unittests.rst | 63 ++++++++++--------- examples/versioned_history/__init__.py | 6 +- lib/sqlalchemy/testing/fixtures.py | 2 +- lib/sqlalchemy/testing/plugin/plugin_base.py | 4 +- lib/sqlalchemy/testing/plugin/pytestplugin.py | 4 +- lib/sqlalchemy/testing/provision.py | 2 +- test/base/test_tutorials.py | 2 +- test/conftest.py | 4 +- 9 files changed, 47 insertions(+), 44 deletions(-) diff --git a/README.dialects.rst b/README.dialects.rst index 7335c0f0ea..f5a15c8be5 100644 --- 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 74c652046e..ed66ce5648 100644 --- 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 3deb7fcb2f..53c9c498e1 100644 --- 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 e5e6c42fc0..98d6b2b868 100644 --- 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 2955a05063..2b062cee4a 100644 --- 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 2c2cc398e8..6fa93189cc 100644 --- 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 0123ea7e7a..660a3bd24c 100644 --- 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 b8322db0a9..07444f1241 100644 --- 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 cdabc97850..bd809345b9 100755 --- 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. -- 2.39.5