From: Gord Thompson Date: Thu, 16 Apr 2020 22:06:36 +0000 (-0600) Subject: Rename py.test to pytest X-Git-Tag: rel_1_4_0b1~376^2 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=405fc9717048b0adc852a72da540048df7a8142a;p=thirdparty%2Fsqlalchemy%2Fsqlalchemy.git Rename py.test to pytest Change-Id: I431e1ef41e26d490343204a75a5c097768749768 --- diff --git a/README.dialects.rst b/README.dialects.rst index b300128bb2..e4bf7f2d22 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 47ae3c7cd6..14b1bbcafb 100644 --- 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 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 26ae221b89..a4399830e9 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 29dab098ae..9b2f6911da 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. """ @@ -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 f2e7d706f6..9dc40c9fef 100644 --- 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 b6108400d2..24e96dfab4 100644 --- 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 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 97dca753de..4b8de298b4 100644 --- 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 6f7fe460d3..5c6b89fde7 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. """ @@ -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.