undo

kingbuzzman · kingbuzzman · commit 34582a41267a · 2025-08-12T10:07:46.000-04:00
diff --git a/docs/faq.rst b/docs/faq.rst
@@ -79,7 +79,7 @@ How can I use ``manage.py test`` with pytest-django?
 ----------------------------------------------------
 
 pytest-django is designed to work with the ``pytest`` command, but if you
-really need integration with ``manage.py test``, you can add this class path
+really need integration with ``manage.py test``, you can add this class path 
 in your Django settings:
 
 .. code-block:: python
diff --git a/docs/helpers.rst b/docs/helpers.rst
@@ -28,82 +28,82 @@ dynamically in a hook or fixture.
 
 .. decorator:: pytest.mark.django_db([transaction=False, reset_sequences=False, databases=None, serialized_rollback=False, available_apps=None])
 
-    This is used to mark a test function as requiring the database. It
-    will ensure the database is set up correctly for the test. Each test
-    will run in its own transaction which will be rolled back at the end
-    of the test. This behavior is the same as Django's standard
-    :class:`~django.test.TestCase` class.
-
-    In order for a test to have access to the database it must either be marked
-    using the :func:`~pytest.mark.django_db` mark or request one of the :fixture:`db`,
-    :fixture:`transactional_db` or :fixture:`django_db_reset_sequences` fixtures.
-    Otherwise the test will fail when trying to access the database.
-
-    :type transaction: bool
-    :param transaction:
-        The ``transaction`` argument will allow the test to use real transactions.
-        With ``transaction=False`` (the default when not specified), transaction
-        operations are noops during the test. This is the same behavior that
-        :class:`django.test.TestCase` uses. When ``transaction=True``, the behavior
-        will be the same as :class:`django.test.TransactionTestCase`.
-
-
-    :type reset_sequences: bool
-    :param reset_sequences:
-        The ``reset_sequences`` argument will ask to reset auto increment sequence
-        values (e.g. primary keys) before running the test.  Defaults to
-        ``False``.  Must be used together with ``transaction=True`` to have an
-        effect.  Please be aware that not all databases support this feature.
-        For details see :attr:`django.test.TransactionTestCase.reset_sequences`.
-
-
-    :type databases: Iterable[str] | str | None
-    :param databases:
-
-        The ``databases`` argument defines which databases in a multi-database
-        configuration will be set up and may be used by the test.  Defaults to
-        only the ``default`` database.  The special value ``"__all__"`` may be used
-        to specify all configured databases.
-        For details see :attr:`django.test.TransactionTestCase.databases` and
-        :attr:`django.test.TestCase.databases`.
-
-    :type serialized_rollback: bool
-    :param serialized_rollback:
-        The ``serialized_rollback`` argument enables :ref:`rollback emulation
-        <test-case-serialized-rollback>`.  After a transactional test (or any test
-        using a database backend which doesn't support transactions) runs, the
-        database is flushed, destroying data created in data migrations.  Setting
-        ``serialized_rollback=True`` tells Django to serialize the database content
-        during setup, and restore it during teardown.
-
-        Note that this will slow down that test suite by approximately 3x.
-
-    :type available_apps: Iterable[str] | None
-    :param available_apps:
-        .. caution::
-
-            This argument is **experimental** and is subject to change without
-            deprecation.
-
-        The ``available_apps`` argument defines a subset of apps that are enabled
-        for a specific set of tests. Setting ``available_apps`` configures models
-        for which types/permissions will be created before each test, and which
-        model tables will be emptied after each test (this truncation may cascade
-        to unavailable apps models).
-
-        For details see :attr:`django.test.TransactionTestCase.available_apps`
+  This is used to mark a test function as requiring the database. It
+  will ensure the database is set up correctly for the test. Each test
+  will run in its own transaction which will be rolled back at the end
+  of the test. This behavior is the same as Django's standard
+  :class:`~django.test.TestCase` class.
+
+  In order for a test to have access to the database it must either be marked
+  using the :func:`~pytest.mark.django_db` mark or request one of the :fixture:`db`,
+  :fixture:`transactional_db` or :fixture:`django_db_reset_sequences` fixtures.
+  Otherwise the test will fail when trying to access the database.
+
+  :type transaction: bool
+  :param transaction:
+    The ``transaction`` argument will allow the test to use real transactions.
+    With ``transaction=False`` (the default when not specified), transaction
+    operations are noops during the test. This is the same behavior that
+    :class:`django.test.TestCase` uses. When ``transaction=True``, the behavior
+    will be the same as :class:`django.test.TransactionTestCase`.
+
+
+  :type reset_sequences: bool
+  :param reset_sequences:
+    The ``reset_sequences`` argument will ask to reset auto increment sequence
+    values (e.g. primary keys) before running the test.  Defaults to
+    ``False``.  Must be used together with ``transaction=True`` to have an
+    effect.  Please be aware that not all databases support this feature.
+    For details see :attr:`django.test.TransactionTestCase.reset_sequences`.
+
+
+  :type databases: Iterable[str] | str | None
+  :param databases:
+
+    The ``databases`` argument defines which databases in a multi-database
+    configuration will be set up and may be used by the test.  Defaults to
+    only the ``default`` database.  The special value ``"__all__"`` may be used
+    to specify all configured databases.
+    For details see :attr:`django.test.TransactionTestCase.databases` and
+    :attr:`django.test.TestCase.databases`.
+
+  :type serialized_rollback: bool
+  :param serialized_rollback:
+    The ``serialized_rollback`` argument enables :ref:`rollback emulation
+    <test-case-serialized-rollback>`.  After a transactional test (or any test
+    using a database backend which doesn't support transactions) runs, the
+    database is flushed, destroying data created in data migrations.  Setting
+    ``serialized_rollback=True`` tells Django to serialize the database content
+    during setup, and restore it during teardown.
+
+    Note that this will slow down that test suite by approximately 3x.
+
+  :type available_apps: Iterable[str] | None
+  :param available_apps:
+    .. caution::
+
+      This argument is **experimental** and is subject to change without
+      deprecation.
+
+    The ``available_apps`` argument defines a subset of apps that are enabled
+    for a specific set of tests. Setting ``available_apps`` configures models
+    for which types/permissions will be created before each test, and which
+    model tables will be emptied after each test (this truncation may cascade
+    to unavailable apps models).
+
+    For details see :attr:`django.test.TransactionTestCase.available_apps`
 
 
 .. note::
 
-    If you want access to the Django database inside a *fixture*, this marker may
-    or may not help even if the function requesting your fixture has this marker
-    applied, depending on pytest's fixture execution order. To access the database
-    in a fixture, it is recommended that the fixture explicitly request one of the
-    :fixture:`db`, :fixture:`transactional_db`,
-    :fixture:`django_db_reset_sequences` or
-    :fixture:`django_db_serialized_rollback` fixtures. See below for a description
-    of them.
+  If you want access to the Django database inside a *fixture*, this marker may
+  or may not help even if the function requesting your fixture has this marker
+  applied, depending on pytest's fixture execution order. To access the database
+  in a fixture, it is recommended that the fixture explicitly request one of the
+  :fixture:`db`, :fixture:`transactional_db`,
+  :fixture:`django_db_reset_sequences` or
+  :fixture:`django_db_serialized_rollback` fixtures. See below for a description
+  of them.
 
 .. note:: Automatic usage with ``django.test.TestCase``.
 
@@ -118,36 +118,36 @@ dynamically in a hook or fixture.
 
 .. decorator:: pytest.mark.urls(urls)
 
-    Specify a different ``settings.ROOT_URLCONF`` module for the marked tests.
+   Specify a different ``settings.ROOT_URLCONF`` module for the marked tests.
 
-    :type urls: str
-    :param urls:
-        The urlconf module to use for the test, e.g. ``myapp.test_urls``.  This is
-        similar to Django's ``TestCase.urls`` attribute.
+   :type urls: str
+   :param urls:
+     The urlconf module to use for the test, e.g. ``myapp.test_urls``.  This is
+     similar to Django's ``TestCase.urls`` attribute.
 
-    Example usage::
+   Example usage::
 
-        @pytest.mark.urls('myapp.test_urls')
-        def test_something(client):
-            assert b'Success!' in client.get('/some_url_defined_in_test_urls/').content
+     @pytest.mark.urls('myapp.test_urls')
+     def test_something(client):
+         assert b'Success!' in client.get('/some_url_defined_in_test_urls/').content
 
 
 ``pytest.mark.ignore_template_errors`` - ignore invalid template variables
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 .. decorator:: pytest.mark.ignore_template_errors
 
-    Ignore errors when using the ``--fail-on-template-vars`` option, i.e.
-    do not cause tests to fail if your templates contain invalid variables.
+  Ignore errors when using the ``--fail-on-template-vars`` option, i.e.
+  do not cause tests to fail if your templates contain invalid variables.
 
-    This marker sets the ``string_if_invalid`` template option.
-    See :ref:`django:invalid-template-variables`.
+  This marker sets the ``string_if_invalid`` template option.
+  See :ref:`django:invalid-template-variables`.
 
-    Example usage::
+  Example usage::
 
-        @pytest.mark.ignore_template_errors
-        def test_something(client):
-            client('some-url-with-invalid-template-vars')
+     @pytest.mark.ignore_template_errors
+     def test_something(client):
+         client('some-url-with-invalid-template-vars')
 
 
 Fixtures
@@ -383,15 +383,15 @@ created in data migrations, you should add the
 
 .. note:: Combining database access fixtures.
 
-    When using multiple database fixtures together, only one of them is
-    used.  Their order of precedence is as follows (the last one wins):
+  When using multiple database fixtures together, only one of them is
+  used.  Their order of precedence is as follows (the last one wins):
 
-    * ``db``
-    * ``transactional_db``
+  * ``db``
+  * ``transactional_db``
 
-    In addition, using ``live_server`` or ``django_db_reset_sequences`` will also
-    trigger transactional database access, and ``django_db_serialized_rollback``
-    regular database access, if not specified.
+  In addition, using ``live_server`` or ``django_db_reset_sequences`` will also
+  trigger transactional database access, and ``django_db_serialized_rollback``
+  regular database access, if not specified.
 
 .. fixture:: settings
 
@@ -419,10 +419,10 @@ Example
 
 .. py:function:: django_assert_num_queries(num, connection=None, info=None, *, using=None)
 
-    :param num: expected number of queries
-    :param connection: optional database connection
-    :param str info: optional info message to display on failure
-    :param str using: optional database alias
+  :param num: expected number of queries
+  :param connection: optional database connection
+  :param str info: optional info message to display on failure
+  :param str using: optional database alias
 
 This fixture allows to check for an expected number of DB queries.
 
@@ -459,10 +459,10 @@ If you use type annotations, you can annotate the fixture like this::
 
 .. py:function:: django_assert_max_num_queries(num, connection=None, info=None, *, using=None)
 
-    :param num: expected maximum number of queries
-    :param connection: optional database connection
-    :param str info: optional info message to display on failure
-    :param str using: optional database alias
+  :param num: expected maximum number of queries
+  :param connection: optional database connection
+  :param str info: optional info message to display on failure
+  :param str using: optional database alias
 
 This fixture allows to check for an expected maximum number of DB queries.
 
@@ -492,12 +492,12 @@ If you use type annotations, you can annotate the fixture like this::
 
 .. py:function:: django_capture_on_commit_callbacks(*, using=DEFAULT_DB_ALIAS, execute=False)
 
-    :param using:
-        The alias of the database connection to capture callbacks for.
-    :param execute:
-        If True, all the callbacks will be called as the context manager exits, if
-        no exception occurred. This emulates a commit after the wrapped block of
-        code.
+  :param using:
+    The alias of the database connection to capture callbacks for.
+  :param execute:
+    If True, all the callbacks will be called as the context manager exits, if
+    no exception occurred. This emulates a commit after the wrapped block of
+    code.
 
 .. versionadded:: 4.4
 
diff --git a/docs/index.rst b/docs/index.rst
@@ -13,7 +13,7 @@ Quick Start
 
 .. code-block:: bash
 
-    $ pip install pytest-django
+   $ pip install pytest-django
 
 Make sure ``DJANGO_SETTINGS_MODULE`` is defined (see
 :ref:`configuring_django_settings`) and make your tests discoverable
@@ -24,28 +24,28 @@ Example using pytest.ini or tox.ini
 
 .. code-block:: ini
 
-    # -- FILE: pytest.ini (or tox.ini)
-    [pytest]
-    DJANGO_SETTINGS_MODULE = test.settings
-    # -- recommended but optional:
-    python_files = tests.py test_*.py *_tests.py
+   # -- FILE: pytest.ini (or tox.ini)
+   [pytest]
+   DJANGO_SETTINGS_MODULE = test.settings
+   # -- recommended but optional:
+   python_files = tests.py test_*.py *_tests.py
 
 Example using pyproject.toml
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 .. code-block:: toml
 
-    # -- Example FILE: pyproject.toml
-    [tool.pytest.ini_options]
-    DJANGO_SETTINGS_MODULE = "test.settings"
-    # -- recommended but optional:
-    python_files = ["test_*.py", "*_test.py", "testing/python/*.py"]
+   # -- Example FILE: pyproject.toml
+   [tool.pytest.ini_options]
+   DJANGO_SETTINGS_MODULE = "test.settings"
+   # -- recommended but optional:
+   python_files = ["test_*.py", "*_test.py", "testing/python/*.py"]
 
 Run your tests with ``pytest``:
 
 .. code-block:: bash
 
-    $ pytest
+   $ pytest
 
 Why would I use this instead of Django's manage.py test command?
 ================================================================
@@ -73,17 +73,17 @@ Table of Contents
 =================
 
 .. toctree::
-    :maxdepth: 3
-
-    tutorial
-    configuring_django
-    managing_python_path
-    usage
-    database
-    helpers
-    faq
-    contributing
-    changelog
+   :maxdepth: 3
+
+   tutorial
+   configuring_django
+   managing_python_path
+   usage
+   database
+   helpers
+   faq
+   contributing
+   changelog
 
 Indices and Tables
 ==================
diff --git a/docs/managing_python_path.rst b/docs/managing_python_path.rst
@@ -87,7 +87,7 @@ You can explicitly add paths to the Python search path using pytest's
 Example: project with src layout
 ````````````````````````````````
 
-For a Django package using the ``src`` layout, with test settings located in a
+For a Django package using the ``src`` layout, with test settings located in a 
 ``tests`` package at the top level::
 
     myproj
diff --git a/docs/usage.rst b/docs/usage.rst
@@ -33,7 +33,7 @@ You can switch it on in `pytest.ini`::
 
     [pytest]
     FAIL_INVALID_TEMPLATE_VARS = True
-
+    
 Additional pytest.ini settings
 ------------------------------
 
