Skip to content

Commit ff2c649

Browse files
committed
Documentation markup fixes.
1 parent 65e080f commit ff2c649

File tree

2 files changed

+44
-42
lines changed

2 files changed

+44
-42
lines changed

docs/database.rst

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -9,8 +9,8 @@ minimum which is a best practice since next-to-no business logic
99
should be requiring the database. Moreover it makes it very clear
1010
what code uses the database and catches any mistakes.
1111

12-
Enabling database access
13-
------------------------
12+
Enabling database access in tests
13+
---------------------------------
1414

1515
You can use `py.test marks <http://pytest.org/latest/mark.html>`_ to
1616
tell ``pytest-django`` your test needs database access::

docs/helpers.rst

Lines changed: 42 additions & 40 deletions
Original file line numberDiff line numberDiff line change
@@ -13,46 +13,46 @@ on what marks are and for notes on using_ them.
1313
.. _using: http://pytest.org/latest/example/markers.html#marking-whole-classes-or-modules
1414

1515

16-
``pytest.mark.django_db`` - request database access
17-
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
18-
19-
.. py:function:: pytest.mark.django_db([transaction=False])
20-
21-
This is used to mark a test function as requiring the database. It
22-
will ensure the database is setup correctly for the test. Each test
23-
will run in its own transaction which will be rolled back at the end
24-
of the test. This behavior is the same as Django's standard
25-
`django.test.TestCase`_ class.
26-
27-
In order for a test to have access to the database it must either
28-
be marked using the ``django_db`` mark or request one of the ``db``
29-
or ``transactional_db`` fixtures. Otherwise the test will fail
30-
when trying to access the database.
31-
32-
:type transaction: bool
33-
:param transaction:
34-
The ``transaction`` argument will allow the test to use real transactions.
35-
With ``transaction=False`` (the default when not specified), transaction
36-
operations are noops during the test. This is the same behavior that
37-
`django.test.TestCase`_
38-
uses. When ``transaction=True``, the behavior will be the same as
39-
`django.test.TransactionTestCase`_
40-
41-
.. note::
42-
43-
If you want access to the Django database *inside a fixture*
44-
this marker will not help even if the function requesting your
45-
fixture has this marker applied. To access the database in a
46-
fixture, the fixture itself will have to request the ``db`` or
47-
``transactional_db`` fixture. See below for a description of
48-
them.
49-
50-
.. note:: Automatic usage with ``django.test.TestCase``.
51-
52-
Test classes that subclass `django.test.TestCase`_ will have access to
53-
the database always to make them compatible with existing Django tests.
54-
Test classes that subclass Python's ``unittest.TestCase`` need to have the
55-
marker applied in order to access the database.
16+
``pytest.mark.django_db(transaction=False)`` - request database access
17+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
18+
19+
.. :py:function:: pytest.mark.django_db:
20+
21+
This is used to mark a test function as requiring the database. It
22+
will ensure the database is setup correctly for the test. Each test
23+
will run in its own transaction which will be rolled back at the end
24+
of the test. This behavior is the same as Django's standard
25+
`django.test.TestCase`_ class.
26+
27+
In order for a test to have access to the database it must either
28+
be marked using the ``django_db`` mark or request one of the ``db``
29+
or ``transactional_db`` fixtures. Otherwise the test will fail
30+
when trying to access the database.
31+
32+
:type transaction: bool
33+
:param transaction:
34+
The ``transaction`` argument will allow the test to use real transactions.
35+
With ``transaction=False`` (the default when not specified), transaction
36+
operations are noops during the test. This is the same behavior that
37+
`django.test.TestCase`_
38+
uses. When ``transaction=True``, the behavior will be the same as
39+
`django.test.TransactionTestCase`_
40+
41+
.. note::
42+
43+
If you want access to the Django database *inside a fixture*
44+
this marker will not help even if the function requesting your
45+
fixture has this marker applied. To access the database in a
46+
fixture, the fixture itself will have to request the ``db`` or
47+
``transactional_db`` fixture. See below for a description of
48+
them.
49+
50+
.. note:: Automatic usage with ``django.test.TestCase``.
51+
52+
Test classes that subclass `django.test.TestCase`_ will have access to
53+
the database always to make them compatible with existing Django tests.
54+
Test classes that subclass Python's ``unittest.TestCase`` need to have the
55+
marker applied in order to access the database.
5656

5757
.. _django.test.TestCase: https://docs.djangoproject.com/en/dev/topics/testing/overview/#testcase
5858
.. _django.test.TransactionTestCase: https://docs.djangoproject.com/en/dev/topics/testing/overview/#transactiontestcase
@@ -178,6 +178,8 @@ The field name used for the username on the user model.
178178
``db``
179179
~~~~~~~
180180

181+
.. fixture:: db
182+
181183
This fixture will ensure the Django database is set up. This only
182184
required for fixtures which want to use the database themselves. A
183185
test function should normally use the :py:func:`~pytest.mark.django_db`

0 commit comments

Comments
 (0)