pytest-django
registers and uses markers. See the pytest documentation on what marks are and for notes on using them.
This is used to mark a test function as requiring the database. It will ensure the database is setup 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 django.test.TestCase class.
In order for a test to have access to the database it must either be marked using the django_db
mark or request one of the db
or transactional_db
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. Withtransaction=False
(the default when not specified), transaction operations are noops during the test. This is the same behavior that django.test.TestCase uses. Whentransaction=True
, the behavior will be the same as django.test.TransactionTestCase
Note
If you want access to the Django database inside a fixture this marker will not help even if the function requesting your fixture has this marker applied. To access the database in a fixture, the fixture itself will have to request the db
or transactional_db
fixture. See below for a description of them.
Note
Automatic usage with django.test.TestCase
.
Test classes that subclass django.test.TestCase will have access to the database always to make them compatible with existing Django tests. Test classes that subclass Python's unittest.TestCase
need to have the marker applied in order to access the database.
pytest-django provides some pytest fixtures to provide dependencies for tests. More information on fixtures is available in the pytest documentation.
An instance of a django.test.RequestFactory
from myapp.views import my_view
def test_details(rf):
request = rf.get('/customer/details')
response = my_view(request)
assert response.status_code == 200
An instance of a django.test.Client
def test_with_client(client):
response = client.get('/')
assert response.content == 'Foobar'
An instance of a django.test.Client, that is logged in as an admin user.
def test_an_admin_view(admin_client):
response = admin_client.get('/admin/')
assert response.status_code == 200
As an extra bonus this will automatically mark the database using the django_db
mark.
An instance of a superuser, with username "admin" and password "password" (in case there is no "admin" user yet).
As an extra bonus this will automatically mark the database using the django_db
mark.
The user model used by Django. This handles different versions of Django.
The field name used for the username on the user model.
db
This fixture will ensure the Django database is set up. This only required for fixtures which want to use the database themselves. A test function should normally use the :py~pytest.mark.django_db
mark to signal it needs the database.
This fixture can be used to request access to the database including transaction support. This is only required for fixtures which need database access themselves. A test function would normally use the :py~pytest.mark.django_db
mark to signal it needs the database.
This fixture runs a live Django server in a background thread. The server's URL can be retrieved using the live_server.url
attribute or by requesting it's string value: unicode(live_server)
. You can also directly concatenate a string to form a URL: live_server + '/foo
.
This fixture will provide a handle on the Django settings module, and automatically revert any changes made to the settings (modifications, additions and deletions).
def test_with_specific_settings(settings):
settings.USE_TZ = True
assert settings.USE_TZ
This fixture allows to check for an expected number of DB queries. It currently only supports the default database.
def test_queries(assert_num_queries):
with django_assert_num_queries(3):
Item.objects.create('foo')
Item.objects.create('bar')
Item.objects.create('baz')
A clean mail outbox where Django emails are being sent to.
from django.core import mail
def test_mail(mailoutbox):
mail.send_mail('subject', 'body', 'from@example.com', ['to@example.com'])
assert len(mailoutbox) == 1
m = mailoutbox[0]
assert m.subject == 'subject'
assert m.body == 'body'
assert m.from_email == 'from@example.com'
assert list(m.to) == ['to@example.com']
pytest-django provides some pytest fixtures that are of autouse nature. They provide functionality to assure a clean environment during tests.
If django.contrib.sites
is in your INSTALLED_APPS, Site cache will be cleared for each test to avoid hitting the cache and cause wrong Site object to be returned by Site.objects.get_current()
.
mail.outbox
will be cleared for each pytest, to give tests a empty mailbox. It is however more pytestic to use the mailoutbox
fixture to access mail.outbox
.