@@ -113,8 +113,8 @@ More information on fixtures is available in the `pytest documentation
113
113
<https://pytest.org/en/latest/fixture.html> `_.
114
114
115
115
116
- ``rf `` - ``RequestFactory ``
117
- ~~~~~~~~~~~~~~~~~~~~~~~~~~~
116
+ ``django_rf `` - ``RequestFactory ``
117
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
118
118
119
119
An instance of a `django.test.RequestFactory `_
120
120
@@ -127,13 +127,13 @@ Example
127
127
128
128
from myapp.views import my_view
129
129
130
- def test_details(rf ):
131
- request = rf .get('/customer/details')
130
+ def test_details(django_rf ):
131
+ request = django_rf .get('/customer/details')
132
132
response = my_view(request)
133
133
assert response.status_code == 200
134
134
135
- ``client `` - ``django.test.Client ``
136
- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
135
+ ``django_client `` - ``django.test.Client ``
136
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
137
137
138
138
An instance of a `django.test.Client `_
139
139
@@ -144,25 +144,25 @@ Example
144
144
145
145
::
146
146
147
- def test_with_client(client ):
148
- response = client .get('/')
147
+ def test_with_client(django_client ):
148
+ response = django_client .get('/')
149
149
assert response.content == 'Foobar'
150
150
151
151
To use `client ` as an authenticated standard user, call its `login() ` method before accessing a URL:
152
152
153
153
::
154
154
155
- def test_with_authenticated_client(client , django_user_model):
155
+ def test_with_authenticated_client(django_client , django_user_model):
156
156
username = "user1"
157
157
password = "bar"
158
158
django_user_model.objects.create_user(username=username, password=password)
159
159
client.login(username=username, password=password)
160
- response = client .get('/private')
160
+ response = django_client .get('/private')
161
161
assert response.content == 'Protected Area'
162
162
163
163
164
- ``admin_client `` - ``django.test.Client `` logged in as admin
165
- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
164
+ ``django_admin_client `` - ``django.test.Client `` logged in as admin
165
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
166
166
167
167
An instance of a `django.test.Client `_, logged in as an admin user.
168
168
@@ -171,23 +171,23 @@ Example
171
171
172
172
::
173
173
174
- def test_an_admin_view(admin_client ):
175
- response = admin_client .get('/admin/')
174
+ def test_an_admin_view(django_admin_client ):
175
+ response = adjango_dmin_client .get('/admin/')
176
176
assert response.status_code == 200
177
177
178
- Using the `admin_client ` fixture will cause the test to automatically be marked for database use (no need to specify the
179
- ``django_db `` mark).
178
+ Using the `django_admin_client ` fixture will cause the test to automatically be
179
+ marked for database use (no need to specify the ``django_db `` mark).
180
180
181
181
.. fixture :: admin_user
182
182
183
- ``admin_user `` - an admin user (superuser)
184
- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
183
+ ``django_admin_user `` - an admin user (superuser)
184
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
185
185
186
186
An instance of a superuser, with username "admin" and password "password" (in
187
187
case there is no "admin" user yet).
188
188
189
- Using the `admin_user ` fixture will cause the test to automatically be marked for database use (no need to specify the
190
- ``django_db `` mark).
189
+ Using the `django_admin_user ` fixture will cause the test to automatically be
190
+ marked for database use (no need to specify the ``django_db `` mark).
191
191
192
192
193
193
``django_user_model ``
@@ -213,18 +213,18 @@ This fixture extracts the field name used for the username on the user model, i.
213
213
``settings.USERNAME_FIELD ``. Use this fixture to make pluggable apps testable regardless what the username field
214
214
is configured to be in the containing Django project.
215
215
216
- ``db ``
217
- ~~~~~~~
216
+ ``django_db ``
217
+ ~~~~~~~~~~~~~
218
218
219
- .. fixture :: db
219
+ .. fixture :: django_db
220
220
221
221
This fixture will ensure the Django database is set up. Only
222
222
required for fixtures that want to use the database themselves. A
223
223
test function should normally use the ``pytest.mark.django_db ``
224
224
mark to signal it needs the database.
225
225
226
- ``transactional_db ``
227
- ~~~~~~~~~~~~~~~~~~~~
226
+ ``django_transactional_db ``
227
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~
228
228
229
229
This fixture can be used to request access to the database including
230
230
transaction support. This is only required for fixtures which need
@@ -242,13 +242,13 @@ sequences (if your database supports it). This is only required for
242
242
fixtures which need database access themselves. A test function should
243
243
normally use the ``pytest.mark.django_db `` mark with ``transaction=True `` and ``reset_sequences=True ``.
244
244
245
- ``live_server ``
246
- ~~~~~~~~~~~~~~~
245
+ ``django_live_server ``
246
+ ~~~~~~~~~~~~~~~~~~~~~~
247
247
248
248
This fixture runs a live Django server in a background thread. The
249
- server's URL can be retrieved using the ``live_server .url `` attribute
250
- or by requesting it's string value: ``unicode(live_server ) ``. You can
251
- also directly concatenate a string to form a URL: ``live_server +
249
+ server's URL can be retrieved using the ``django_live_server .url `` attribute
250
+ or by requesting it's string value: ``unicode(django_live_server ) ``. You can
251
+ also directly concatenate a string to form a URL: ``django_live_server +
252
252
'/foo ``.
253
253
254
254
.. note :: Combining database access fixtures.
@@ -260,11 +260,11 @@ also directly concatenate a string to form a URL: ``live_server +
260
260
* ``transactional_db ``
261
261
* ``django_db_reset_sequences ``
262
262
263
- In addition, using ``live_server `` will also trigger transactional
263
+ In addition, using ``django_live_server `` will also trigger transactional
264
264
database access, if not specified.
265
265
266
- ``settings ``
267
- ~~~~~~~~~~~~
266
+ ``django_settings ``
267
+ ~~~~~~~~~~~~~~~~~~~
268
268
269
269
This fixture will provide a handle on the Django settings module, and
270
270
automatically revert any changes made to the settings (modifications, additions
@@ -275,9 +275,9 @@ Example
275
275
276
276
::
277
277
278
- def test_with_specific_settings(settings ):
279
- settings .USE_TZ = True
280
- assert settings .USE_TZ
278
+ def test_with_specific_settings(django_settings ):
279
+ django_settings .USE_TZ = True
280
+ assert django_settings .USE_TZ
281
281
282
282
283
283
.. fixture :: django_assert_num_queries
@@ -333,8 +333,8 @@ Example usage::
333
333
Item.objects.create('bar')
334
334
335
335
336
- ``mailoutbox ``
337
- ~~~~~~~~~~~~~~
336
+ ``django_mailoutbox ``
337
+ ~~~~~~~~~~~~~~~~~~~~~
338
338
339
339
A clean email outbox to which Django-generated emails are sent.
340
340
@@ -345,10 +345,10 @@ Example
345
345
346
346
from django.core import mail
347
347
348
- def test_mail(mailoutbox ):
348
+ def test_mail(django_mailoutbox ):
349
349
mail.send_mail('subject', 'body', '[email protected] ', ['[email protected] '])
350
- assert len(mailoutbox ) == 1
351
- m = mailoutbox [0]
350
+ assert len(django_mailoutbox ) == 1
351
+ m = django_mailoutbox [0]
352
352
assert m.subject == 'subject'
353
353
assert m.body == 'body'
354
354
assert m.from_email == '[email protected] '
@@ -379,5 +379,6 @@ Clearing of mail.outbox
379
379
~~~~~~~~~~~~~~~~~~~~~~~
380
380
381
381
``mail.outbox `` will be cleared for each pytest, to give each new test an empty
382
- mailbox to work with. However, it's more "pytestic" to use the ``mailoutbox `` fixture described above
383
- than to access ``mail.outbox ``.
382
+ mailbox to work with.
383
+ However, it's more "pytestic" to use the ``django_mailoutbox `` fixture
384
+ described above than to access ``mail.outbox ``.
0 commit comments