Upgrade blacken-doc to black's 2024 style (#11899)

This commit is contained in:
Pierre Sassoulas 2024-01-31 13:53:21 +01:00 committed by GitHub
parent de161f8791
commit 4546d5445a
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
7 changed files with 42 additions and 83 deletions

View File

@ -8,7 +8,7 @@ repos:
rev: 1.16.0
hooks:
- id: blacken-docs
additional_dependencies: [black==23.7.0]
additional_dependencies: [black==24.1.1]
- repo: https://github.com/pre-commit/pre-commit-hooks
rev: v4.5.0
hooks:

View File

@ -33,13 +33,11 @@ have been available since years and should be used instead.
.. code-block:: python
@pytest.mark.tryfirst
def pytest_runtest_call():
...
def pytest_runtest_call(): ...
# or
def pytest_runtest_call():
...
def pytest_runtest_call(): ...
pytest_runtest_call.tryfirst = True
@ -49,8 +47,7 @@ should be changed to:
.. code-block:: python
@pytest.hookimpl(tryfirst=True)
def pytest_runtest_call():
...
def pytest_runtest_call(): ...
Changed ``hookimpl`` attributes:
@ -146,8 +143,7 @@ Applying a mark to a fixture function never had any effect, but it is a common u
@pytest.mark.usefixtures("clean_database")
@pytest.fixture
def user() -> User:
...
def user() -> User: ...
Users expected in this case that the ``usefixtures`` mark would have its intended effect of using the ``clean_database`` fixture when ``user`` was invoked, when in fact it has no effect at all.
@ -308,11 +304,9 @@ they are in fact part of the ``nose`` support.
def teardown(self):
self.resource.close()
def test_foo(self):
...
def test_foo(self): ...
def test_bar(self):
...
def test_bar(self): ...
@ -327,11 +321,9 @@ Native pytest support uses ``setup_method`` and ``teardown_method`` (see :ref:`x
def teardown_method(self):
self.resource.close()
def test_foo(self):
...
def test_foo(self): ...
def test_bar(self):
...
def test_bar(self): ...
This is easy to do in an entire code base by doing a simple find/replace.
@ -346,17 +338,14 @@ Code using `@with_setup <with-setup-nose>`_ such as this:
from nose.tools import with_setup
def setup_some_resource():
...
def setup_some_resource(): ...
def teardown_some_resource():
...
def teardown_some_resource(): ...
@with_setup(setup_some_resource, teardown_some_resource)
def test_foo():
...
def test_foo(): ...
Will also need to be ported to a supported pytest style. One way to do it is using a fixture:
@ -365,12 +354,10 @@ Will also need to be ported to a supported pytest style. One way to do it is usi
import pytest
def setup_some_resource():
...
def setup_some_resource(): ...
def teardown_some_resource():
...
def teardown_some_resource(): ...
@pytest.fixture
@ -380,8 +367,7 @@ Will also need to be ported to a supported pytest style. One way to do it is usi
teardown_some_resource()
def test_foo(some_resource):
...
def test_foo(some_resource): ...
.. _`with-setup-nose`: https://nose.readthedocs.io/en/latest/testing_tools.html?highlight=with_setup#nose.tools.with_setup
@ -500,8 +486,7 @@ Implement the :hook:`pytest_load_initial_conftests` hook instead.
.. code-block:: python
def pytest_cmdline_preparse(config: Config, args: List[str]) -> None:
...
def pytest_cmdline_preparse(config: Config, args: List[str]) -> None: ...
# becomes:
@ -509,8 +494,7 @@ Implement the :hook:`pytest_load_initial_conftests` hook instead.
def pytest_load_initial_conftests(
early_config: Config, parser: Parser, args: List[str]
) -> None:
...
) -> None: ...
Collection changes in pytest 8
@ -925,8 +909,7 @@ Applying marks to values of a ``pytest.mark.parametrize`` call is now deprecated
(50, 500),
],
)
def test_foo(a, b):
...
def test_foo(a, b): ...
This code applies the ``pytest.mark.xfail(reason="flaky")`` mark to the ``(6, 36)`` value of the above parametrization
call.
@ -949,8 +932,7 @@ To update the code, use ``pytest.param``:
(50, 500),
],
)
def test_foo(a, b):
...
def test_foo(a, b): ...
.. _pytest_funcarg__ prefix deprecated:
@ -1101,15 +1083,13 @@ This is just a matter of renaming the fixture as the API is the same:
.. code-block:: python
def test_foo(record_xml_property):
...
def test_foo(record_xml_property): ...
Change to:
.. code-block:: python
def test_foo(record_property):
...
def test_foo(record_property): ...
.. _passing command-line string to pytest.main deprecated:
@ -1271,8 +1251,7 @@ Example of usage:
.. code-block:: python
class MySymbol:
...
class MySymbol: ...
def pytest_namespace():

View File

@ -99,8 +99,7 @@ sets. pytest-2.3 introduces a decorator for use on the factory itself:
.. code-block:: python
@pytest.fixture(params=["mysql", "pg"])
def db(request):
... # use request.param
def db(request): ... # use request.param
Here the factory will be invoked twice (with the respective "mysql"
and "pg" values set as ``request.param`` attributes) and all of
@ -141,8 +140,7 @@ argument:
.. code-block:: python
@pytest.fixture()
def db(request):
...
def db(request): ...
The name under which the funcarg resource can be requested is ``db``.
@ -151,8 +149,7 @@ aka:
.. code-block:: python
def pytest_funcarg__db(request):
...
def pytest_funcarg__db(request): ...
But it is then not possible to define scoping and parametrization.

View File

@ -227,8 +227,7 @@ to use strings:
@pytest.mark.skipif("sys.version_info >= (3,3)")
def test_function():
...
def test_function(): ...
During test function setup the skipif condition is evaluated by calling
``eval('sys.version_info >= (3,0)', namespace)``. The namespace contains
@ -262,8 +261,7 @@ configuration value which you might have added:
.. code-block:: python
@pytest.mark.skipif("not config.getvalue('db')")
def test_function():
...
def test_function(): ...
The equivalent with "boolean conditions" is:

View File

@ -1721,8 +1721,7 @@ You can specify multiple fixtures like this:
.. code-block:: python
@pytest.mark.usefixtures("cleandir", "anotherfixture")
def test():
...
def test(): ...
and you may specify fixture usage at the test module level using :globalvar:`pytestmark`:
@ -1750,8 +1749,7 @@ into an ini-file:
@pytest.mark.usefixtures("my_other_fixture")
@pytest.fixture
def my_fixture_that_sadly_wont_use_my_other_fixture():
...
def my_fixture_that_sadly_wont_use_my_other_fixture(): ...
This generates a deprecation warning, and will become an error in Pytest 8.

View File

@ -47,8 +47,7 @@ which may be passed an optional ``reason``:
.. code-block:: python
@pytest.mark.skip(reason="no way of currently testing this")
def test_the_unknown():
...
def test_the_unknown(): ...
Alternatively, it is also possible to skip imperatively during test execution or setup
@ -93,8 +92,7 @@ when run on an interpreter earlier than Python3.10:
@pytest.mark.skipif(sys.version_info < (3, 10), reason="requires python3.10 or higher")
def test_function():
...
def test_function(): ...
If the condition evaluates to ``True`` during collection, the test function will be skipped,
with the specified reason appearing in the summary when using ``-rs``.
@ -112,8 +110,7 @@ You can share ``skipif`` markers between modules. Consider this test module:
@minversion
def test_function():
...
def test_function(): ...
You can import the marker and reuse it in another test module:
@ -124,8 +121,7 @@ You can import the marker and reuse it in another test module:
@minversion
def test_anotherfunction():
...
def test_anotherfunction(): ...
For larger test suites it's usually a good idea to have one file
where you define the markers which you then consistently apply
@ -232,8 +228,7 @@ expect a test to fail:
.. code-block:: python
@pytest.mark.xfail
def test_function():
...
def test_function(): ...
This test will run but no traceback will be reported when it fails. Instead, terminal
reporting will list it in the "expected to fail" (``XFAIL``) or "unexpectedly
@ -275,8 +270,7 @@ that condition as the first parameter:
.. code-block:: python
@pytest.mark.xfail(sys.platform == "win32", reason="bug in a 3rd party library")
def test_function():
...
def test_function(): ...
Note that you have to pass a reason as well (see the parameter description at
:ref:`pytest.mark.xfail ref`).
@ -289,8 +283,7 @@ You can specify the motive of an expected failure with the ``reason`` parameter:
.. code-block:: python
@pytest.mark.xfail(reason="known parser issue")
def test_function():
...
def test_function(): ...
``raises`` parameter
@ -302,8 +295,7 @@ a single exception, or a tuple of exceptions, in the ``raises`` argument.
.. code-block:: python
@pytest.mark.xfail(raises=RuntimeError)
def test_function():
...
def test_function(): ...
Then the test will be reported as a regular failure if it fails with an
exception not mentioned in ``raises``.
@ -317,8 +309,7 @@ even executed, use the ``run`` parameter as ``False``:
.. code-block:: python
@pytest.mark.xfail(run=False)
def test_function():
...
def test_function(): ...
This is specially useful for xfailing tests that are crashing the interpreter and should be
investigated later.
@ -334,8 +325,7 @@ You can change this by setting the ``strict`` keyword-only parameter to ``True``
.. code-block:: python
@pytest.mark.xfail(strict=True)
def test_function():
...
def test_function(): ...
This will make ``XPASS`` ("unexpectedly passing") results from this test to fail the test suite.

View File

@ -164,8 +164,7 @@ Add warning filters to marked test items.
.. code-block:: python
@pytest.mark.filterwarnings("ignore:.*usage will be deprecated.*:DeprecationWarning")
def test_foo():
...
def test_foo(): ...
.. _`pytest.mark.parametrize ref`:
@ -276,8 +275,7 @@ For example:
.. code-block:: python
@pytest.mark.timeout(10, "slow", method="thread")
def test_function():
...
def test_function(): ...
Will create and attach a :class:`Mark <pytest.Mark>` object to the collected
:class:`Item <pytest.Item>`, which can then be accessed by fixtures or hooks with
@ -294,8 +292,7 @@ Example for using multiple custom markers:
@pytest.mark.timeout(10, "slow", method="thread")
@pytest.mark.slow
def test_function():
...
def test_function(): ...
When :meth:`Node.iter_markers <_pytest.nodes.Node.iter_markers>` or :meth:`Node.iter_markers_with_node <_pytest.nodes.Node.iter_markers_with_node>` is used with multiple markers, the marker closest to the function will be iterated over first. The above example will result in ``@pytest.mark.slow`` followed by ``@pytest.mark.timeout(...)``.