Django2.0手册:Advanced testing topics

The request factory¶

class RequestFactory[source]¶

The RequestFactory shares the same API as
the test client. However, instead of behaving like a browser, the
RequestFactory provides a way to generate a request instance that can
be used as the first argument to any view. This means you can test a
view function the same way as you would test any other function — as
a black box, with exactly known inputs, testing for specific outputs.

The API for the RequestFactory is a slightly
restricted subset of the test client API:

• It only has access to the HTTP methods get(),
  post(), put(),
  delete(), head(),
  options(), and trace().
• These methods accept all the same arguments except for
  follow. Since this is just a factory for producing
  requests, it’s up to you to handle the response.
• It does not support middleware. Session and authentication
  attributes must be supplied by the test itself if required
  for the view to function properly.

from django.contrib.auth.models import AnonymousUser, User
from django.test import RequestFactory, TestCase

from .views import MyView, my_view

class SimpleTest(TestCase):
    def setUp(self):
        # Every test needs access to the request factory.
        self.factory = RequestFactory()
        self.user = User.objects.create_user(
            username='jacob', email='jacob@…', password='top_secret')

    def test_details(self):
        # Create an instance of a GET request.
        request = self.factory.get('/customer/details')

        # Recall that middleware are not supported. You can simulate a
        # logged-in user by setting request.user manually.
        request.user = self.user

        # Or you can simulate an anonymous user by setting request.user to
        # an AnonymousUser instance.
        request.user = AnonymousUser()

        # Test my_view() as if it were deployed at /customer/details
        response = my_view(request)
        # Use this syntax for class-based views.
        response = MyView.as_view()(request)
        self.assertEqual(response.status_code, 200)

Tests and multiple host names¶

The ALLOWED_HOSTS setting is validated when running tests. This
allows the test client to differentiate between internal and external URLs.

Projects that support multitenancy or otherwise alter business logic based on
the request’s host and use custom host names in tests must include those hosts
in ALLOWED_HOSTS.

The first and simplest option to do so is to add the hosts to your settings
file. For example, the test suite for docs.djangoproject.com includes the
following:

from django.test import TestCase

class SearchFormTestCase(TestCase):
    def test_empty_get(self):
        response = self.client.get('/en/dev/search/', HTTP_HOST='docs.djangoproject.dev:8000')
        self.assertEqual(response.status_code, 200)

and the settings file includes a list of the domains supported by the project:

ALLOWED_HOSTS = [
    'www.djangoproject.dev',
    'docs.djangoproject.dev',
    ...
]

Another option is to add the required hosts to ALLOWED_HOSTS using
override_settings() or
modify_settings(). This option may be
preferable in standalone apps that can’t package their own settings file or
for projects where the list of domains is not static (e.g., subdomains for
multitenancy). For example, you could write a test for the domain
http://otherserver/ as follows:

from django.test import TestCase, override_settings

class MultiDomainTestCase(TestCase):
    @override_settings(ALLOWED_HOSTS=['otherserver'])
    def test_other_domain(self):
        response = self.client.get('http://otherserver/foo/bar/')

Disabling ALLOWED_HOSTS checking (ALLOWED_HOSTS = ['*']) when
running tests prevents the test client from raising a helpful error message if
you follow a redirect to an external URL.

Tests and multiple databases¶

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.mysql',
        'NAME': 'myproject',
        'HOST': 'dbprimary',
         # ... plus some other settings
    },
    'replica': {
        'ENGINE': 'django.db.backends.mysql',
        'NAME': 'myproject',
        'HOST': 'dbreplica',
        'TEST': {
            'MIRROR': 'default',
        },
        # ... plus some other settings
    }
}

DATABASES = {
    'default': {
        # ... db settings
        'TEST': {
            'DEPENDENCIES': ['diamonds'],
        },
    },
    'diamonds': {
        # ... db settings
        'TEST': {
            'DEPENDENCIES': [],
        },
    },
    'clubs': {
        # ... db settings
        'TEST': {
            'DEPENDENCIES': ['diamonds'],
        },
    },
    'spades': {
        # ... db settings
        'TEST': {
            'DEPENDENCIES': ['diamonds', 'hearts'],
        },
    },
    'hearts': {
        # ... db settings
        'TEST': {
            'DEPENDENCIES': ['diamonds', 'clubs'],
        },
    }
}

Advanced features of TransactionTestCase¶

TransactionTestCase.available_apps¶

Warning

This attribute is a private API. It may be changed or removed without
a deprecation period in the future, for instance to accommodate changes
in application loading.

It’s used to optimize Django’s own test suite, which contains hundreds
of models but no relations between models in different applications.

By default, available_apps is set to None. After each test, Django
calls flush to reset the database state. This empties all tables
and emits the post_migrate signal, which
re-creates one content type and three permissions for each model. This
operation gets expensive proportionally to the number of models.

Setting available_apps to a list of applications instructs Django to
behave as if only the models from these applications were available. The
behavior of TransactionTestCase changes as follows:

• post_migrate is fired before each
  test to create the content types and permissions for each model in
  available apps, in case they’re missing.
• After each test, Django empties only tables corresponding to models in
  available apps. However, at the database level, truncation may cascade to
  related models in unavailable apps. Furthermore
  post_migrate isn’t fired; it will be
  fired by the next TransactionTestCase, after the correct set of
  applications is selected.

Since the database isn’t fully flushed, if a test creates instances of
models not included in available_apps, they will leak and they may
cause unrelated tests to fail. Be careful with tests that use sessions;
the default session engine stores them in the database.

Since post_migrate isn’t emitted after
flushing the database, its state after a TransactionTestCase isn’t the
same as after a TestCase: it’s missing the rows created by listeners
to post_migrate. Considering the
order in which tests are executed, this isn’t an
issue, provided either all TransactionTestCase in a given test suite
declare available_apps, or none of them.

available_apps is mandatory in Django’s own test suite.

TransactionTestCase.reset_sequences¶

Setting reset_sequences = True on a TransactionTestCase will make
sure sequences are always reset before the test run:

class TestsThatDependsOnPrimaryKeySequences(TransactionTestCase):
    reset_sequences = True

    def test_animal_pk(self):
        lion = Animal.objects.create(name="lion", sound="roar")
        # lion.pk is guaranteed to always be 1
        self.assertEqual(lion.pk, 1)

Unless you are explicitly testing primary keys sequence numbers, it is
recommended that you do not hard code primary key values in tests.

Using reset_sequences = True will slow down the test, since the primary
key reset is a relatively expensive database operation.

Using the Django test runner to test reusable applications¶

If you are writing a reusable application
you may want to use the Django test runner to run your own test suite
and thus benefit from the Django testing infrastructure.

A common practice is a tests directory next to the application code, with the
following structure:

runtests.py
polls/
    __init__.py
    models.py
    ...
tests/
    __init__.py
    models.py
    test_settings.py
    tests.py

Let’s take a look inside a couple of those files:

#!/usr/bin/env python
import os
import sys

import django
from django.conf import settings
from django.test.utils import get_runner

if __name__ == "__main__":
    os.environ['DJANGO_SETTINGS_MODULE'] = 'tests.test_settings'
    django.setup()
    TestRunner = get_runner(settings)
    test_runner = TestRunner()
    failures = test_runner.run_tests(["tests"])
    sys.exit(bool(failures))

This is the script that you invoke to run the test suite. It sets up the
Django environment, creates the test database and runs the tests.

For the sake of clarity, this example contains only the bare minimum
necessary to use the Django test runner. You may want to add
command-line options for controlling verbosity, passing in specific test
labels to run, etc.

SECRET_KEY = 'fake-key'
INSTALLED_APPS = [
    "tests",
]

This file contains the Django settings
required to run your app’s tests.

Again, this is a minimal example; your tests may require additional
settings to run.

Since the tests package is included in INSTALLED_APPS when
running your tests, you can define test-only models in its models.py
file.

Using different testing frameworks¶

Clearly, unittest is not the only Python testing framework. While Django
doesn’t provide explicit support for alternative frameworks, it does provide a
way to invoke tests constructed for an alternative framework as if they were
normal Django tests.

When you run ./manage.py test, Django looks at the TEST_RUNNER
setting to determine what to do. By default, TEST_RUNNER points to
'django.test.runner.DiscoverRunner'. This class defines the default Django
testing behavior. This behavior involves:

1. Performing global pre-test setup.
2. Looking for tests in any file below the current directory whose name matches
   the pattern test*.py.
3. Creating the test databases.
4. Running migrate to install models and initial data into the test
   databases.
5. Running the system checks.
6. Running the tests that were found.
7. Destroying the test databases.
8. Performing global post-test teardown.

If you define your own test runner class and point TEST_RUNNER at
that class, Django will execute your test runner whenever you run
./manage.py test. In this way, it is possible to use any test framework
that can be executed from Python code, or to modify the Django test execution
process to satisfy whatever testing requirements you may have.

Integration with coverage.py¶

Code coverage describes how much source code has been tested. It shows which
parts of your code are being exercised by tests and which are not. It’s an
important part of testing applications, so it’s strongly recommended to check
the coverage of your tests.

Django can be easily integrated with coverage.py, a tool for measuring code
coverage of Python programs. First, install coverage.py. Next, run the
following from your project folder containing manage.py:

coverage run --source='.' manage.py test myapp

This runs your tests and collects coverage data of the executed files in your
project. You can see a report of this data by typing following command:

coverage report

Note that some Django code was executed while running tests, but it is not
listed here because of the source flag passed to the previous command.

For more options like annotated HTML listings detailing missed lines, see the
coverage.py docs.