The RequestFactory shares the same API as\nthe test client. However, instead of behaving like a browser, the\nRequestFactory provides a way to generate a request instance that can\nbe used as the first argument to any view. This means you can test a\nview function the same way as you would test any other function – as\na black box, with exactly known inputs, testing for specific outputs.
The API for the RequestFactory is a slightly\nrestricted subset of the test client API:
It only has access to the HTTP methods get(),\npost(), put(),\ndelete(), head(),\noptions(), and trace().
These methods accept all the same arguments except for\nfollow. Since this is just a factory for producing\nrequests, it’s up to you to handle the response.
It does not support middleware. Session and authentication\nattributes must be supplied by the test itself if required\nfor the view to function properly.
The following is a simple unit test using the request factory:
\nfrom django.contrib.auth.models import AnonymousUser, User\nfrom django.test import TestCase, RequestFactory\n\nfrom .views import MyView, my_view\n\nclass SimpleTest(TestCase):\n def setUp(self):\n # Every test needs access to the request factory.\n self.factory = RequestFactory()\n self.user = User.objects.create_user(\n username='jacob', email='jacob@…', password='top_secret')\n\n def test_details(self):\n # Create an instance of a GET request.\n request = self.factory.get('/customer/details')\n\n # Recall that middleware are not supported. You can simulate a\n # logged-in user by setting request.user manually.\n request.user = self.user\n\n # Or you can simulate an anonymous user by setting request.user to\n # an AnonymousUser instance.\n request.user = AnonymousUser()\n\n # Test my_view() as if it were deployed at /customer/details\n response = my_view(request)\n # Use this syntax for class-based views.\n response = MyView.as_view()(request)\n self.assertEqual(response.status_code, 200)\nThe ALLOWED_HOSTS setting is validated when running tests. This\nallows the test client to differentiate between internal and external URLs.
Projects that support multitenancy or otherwise alter business logic based on\nthe request’s host and use custom host names in tests must include those hosts\nin ALLOWED_HOSTS.
The first and simplest option to do so is to add the hosts to your settings\nfile. For example, the test suite for docs.djangoproject.com includes the\nfollowing:
\nfrom django.test import TestCase\n\nclass SearchFormTestCase(TestCase):\n def test_empty_get(self):\n response = self.client.get('/en/dev/search/', HTTP_HOST='docs.djangoproject.dev:8000')\n self.assertEqual(response.status_code, 200)\nand the settings file includes a list of the domains supported by the project:
\nALLOWED_HOSTS = [\n 'www.djangoproject.dev',\n 'docs.djangoproject.dev',\n ...\n]\nAnother option is to add the required hosts to ALLOWED_HOSTS using\noverride_settings() or\nmodify_settings(). This option may be\npreferable in standalone apps that can’t package their own settings file or\nfor projects where the list of domains is not static (e.g., subdomains for\nmultitenancy). For example, you could write a test for the domain\nhttp://otherserver/ as follows:
from django.test import TestCase, override_settings\n\nclass MultiDomainTestCase(TestCase):\n @override_settings(ALLOWED_HOSTS=['otherserver'])\n def test_other_domain(self):\n response = self.client.get('http://otherserver/foo/bar/')\nDisabling ALLOWED_HOSTS checking (ALLOWED_HOSTS = ['*']) when\nrunning tests prevents the test client from raising a helpful error message if\nyou follow a redirect to an external URL.
If you’re testing a multiple database configuration with primary/replica\n(referred to as master/slave by some databases) replication, this strategy of\ncreating test databases poses a problem.\nWhen the test databases are created, there won’t be any replication,\nand as a result, data created on the primary won’t be seen on the\nreplica.
\nTo compensate for this, Django allows you to define that a database is\na test mirror. Consider the following (simplified) example database\nconfiguration:
\nDATABASES = {\n 'default': {\n 'ENGINE': 'django.db.backends.mysql',\n 'NAME': 'myproject',\n 'HOST': 'dbprimary',\n # ... plus some other settings\n },\n 'replica': {\n 'ENGINE': 'django.db.backends.mysql',\n 'NAME': 'myproject',\n 'HOST': 'dbreplica',\n 'TEST': {\n 'MIRROR': 'default',\n },\n # ... plus some other settings\n }\n}\nIn this setup, we have two database servers: dbprimary, described\nby the database alias default, and dbreplica described by the\nalias replica. As you might expect, dbreplica has been configured\nby the database administrator as a read replica of dbprimary, so in\nnormal activity, any write to default will appear on replica.
If Django created two independent test databases, this would break any\ntests that expected replication to occur. However, the replica\ndatabase has been configured as a test mirror (using the\nMIRROR test setting), indicating that under\ntesting, replica should be treated as a mirror of default.
When the test environment is configured, a test version of replica\nwill not be created. Instead the connection to replica\nwill be redirected to point at default. As a result, writes to\ndefault will appear on replica – but because they are actually\nthe same database, not because there is data replication between the\ntwo databases.
By default, Django will assume all databases depend on the default\ndatabase and therefore always create the default database first.\nHowever, no guarantees are made on the creation order of any other\ndatabases in your test setup.
If your database configuration requires a specific creation order, you\ncan specify the dependencies that exist using the DEPENDENCIES test setting. Consider the following (simplified)\nexample database configuration:
DATABASES = {\n 'default': {\n # ... db settings\n 'TEST': {\n 'DEPENDENCIES': ['diamonds'],\n },\n },\n 'diamonds': {\n # ... db settings\n 'TEST': {\n 'DEPENDENCIES': [],\n },\n },\n 'clubs': {\n # ... db settings\n 'TEST': {\n 'DEPENDENCIES': ['diamonds'],\n },\n },\n 'spades': {\n # ... db settings\n 'TEST': {\n 'DEPENDENCIES': ['diamonds', 'hearts'],\n },\n },\n 'hearts': {\n # ... db settings\n 'TEST': {\n 'DEPENDENCIES': ['diamonds', 'clubs'],\n },\n }\n}\nUnder this configuration, the diamonds database will be created first,\nas it is the only database alias without dependencies. The default and\nclubs alias will be created next (although the order of creation of this\npair is not guaranteed), then hearts, and finally spades.
If there are any circular dependencies in the DEPENDENCIES definition, an\nImproperlyConfigured exception will be raised.
TransactionTestCaseLink to this heading#By default, available_apps is set to None. After each test, Django\ncalls flush to reset the database state. This empties all tables\nand emits the post_migrate signal, which\nre-creates one content type and three permissions for each model. This\noperation gets expensive proportionally to the number of models.
Setting available_apps to a list of applications instructs Django to\nbehave as if only the models from these applications were available. The\nbehavior of TransactionTestCase changes as follows:
post_migrate is fired before each\ntest to create the content types and permissions for each model in\navailable apps, in case they’re missing.
After each test, Django empties only tables corresponding to models in\navailable apps. However, at the database level, truncation may cascade to\nrelated models in unavailable apps. Furthermore\npost_migrate isn’t fired; it will be\nfired by the next TransactionTestCase, after the correct set of\napplications is selected.
Since the database isn’t fully flushed, if a test creates instances of\nmodels not included in available_apps, they will leak and they may\ncause unrelated tests to fail. Be careful with tests that use sessions;\nthe default session engine stores them in the database.
Since post_migrate isn’t emitted after\nflushing the database, its state after a TransactionTestCase isn’t the\nsame as after a TestCase: it’s missing the rows created by listeners\nto post_migrate. Considering the\norder in which tests are executed, this isn’t an\nissue, provided either all TransactionTestCase in a given test suite\ndeclare available_apps, or none of them.
available_apps is mandatory in Django’s own test suite.
Setting reset_sequences = True on a TransactionTestCase will make\nsure sequences are always reset before the test run:
class TestsThatDependsOnPrimaryKeySequences(TransactionTestCase):\n reset_sequences = True\n\n def test_animal_pk(self):\n lion = Animal.objects.create(name="lion", sound="roar")\n # lion.pk is guaranteed to always be 1\n self.assertEqual(lion.pk, 1)\nUnless you are explicitly testing primary keys sequence numbers, it is\nrecommended that you do not hard code primary key values in tests.
\nUsing reset_sequences = True will slow down the test, since the primary\nkey reset is an relatively expensive database operation.
If you are writing a reusable application\nyou may want to use the Django test runner to run your own test suite\nand thus benefit from the Django testing infrastructure.
\nA common practice is a tests directory next to the application code, with the\nfollowing structure:
\nruntests.py\npolls/\n __init__.py\n models.py\n ...\ntests/\n __init__.py\n models.py\n test_settings.py\n tests.py\nLet’s take a look inside a couple of those files:
\nruntests.py#!/usr/bin/env python\nimport os\nimport sys\n\nimport django\nfrom django.conf import settings\nfrom django.test.utils import get_runner\n\nif __name__ == "__main__":\n os.environ['DJANGO_SETTINGS_MODULE'] = 'tests.test_settings'\n django.setup()\n TestRunner = get_runner(settings)\n test_runner = TestRunner()\n failures = test_runner.run_tests(["tests"])\n sys.exit(bool(failures))\nThis is the script that you invoke to run the test suite. It sets up the\nDjango environment, creates the test database and runs the tests.
\nFor the sake of clarity, this example contains only the bare minimum\nnecessary to use the Django test runner. You may want to add\ncommand-line options for controlling verbosity, passing in specific test\nlabels to run, etc.
\ntests/test_settings.pySECRET_KEY = 'fake-key'\nINSTALLED_APPS = [\n "tests",\n]\nThis file contains the Django settings\nrequired to run your app’s tests.
\nAgain, this is a minimal example; your tests may require additional\nsettings to run.
\nSince the tests package is included in INSTALLED_APPS when\nrunning your tests, you can define test-only models in its models.py\nfile.
Clearly, unittest is not the only Python testing framework. While Django\ndoesn’t provide explicit support for alternative frameworks, it does provide a\nway to invoke tests constructed for an alternative framework as if they were\nnormal Django tests.
When you run ./manage.py test, Django looks at the TEST_RUNNER\nsetting to determine what to do. By default, TEST_RUNNER points to\n'django.test.runner.DiscoverRunner'. This class defines the default Django\ntesting behavior. This behavior involves:
Performing global pre-test setup.
Looking for tests in any file below the current directory whose name matches\nthe pattern test*.py.
Creating the test databases.
Running migrate to install models and initial data into the test\ndatabases.
Running the system checks.
Running the tests that were found.
Destroying the test databases.
Performing global post-test teardown.
If you define your own test runner class and point TEST_RUNNER at\nthat class, Django will execute your test runner whenever you run\n./manage.py test. In this way, it is possible to use any test framework\nthat can be executed from Python code, or to modify the Django test execution\nprocess to satisfy whatever testing requirements you may have.
A test runner is a class defining a run_tests() method. Django ships\nwith a DiscoverRunner class that defines the default Django testing\nbehavior. This class defines the run_tests() entry point, plus a\nselection of other methods that are used to by run_tests() to set up,\nexecute and tear down the test suite.
DiscoverRunner will search for tests in any file matching pattern.
top_level can be used to specify the directory containing your\ntop-level Python modules. Usually Django can figure this out automatically,\nso it’s not necessary to specify this option. If specified, it should\ngenerally be the directory containing your manage.py file.
verbosity determines the amount of notification and debug information\nthat will be printed to the console; 0 is no output, 1 is normal\noutput, and 2 is verbose output.
If interactive is True, the test suite has permission to ask the\nuser for instructions when the test suite is executed. An example of this\nbehavior would be asking for permission to delete an existing test\ndatabase. If interactive is False, the test suite must be able to\nrun without any manual intervention.
If failfast is True, the test suite will stop running after the\nfirst test failure is detected.
If keepdb is True, the test suite will use the existing database,\nor create one if necessary. If False, a new database will be created,\nprompting the user to remove the existing one, if present.
If reverse is True, test cases will be executed in the opposite\norder. This could be useful to debug tests that aren’t properly isolated\nand have side effects. Grouping by test class is\npreserved when using this option.
debug_mode specifies what the DEBUG setting should be\nset to prior to running tests.
If debug_sql is True, failing test cases will output SQL queries\nlogged to the django.db.backends logger as well\nas the traceback. If verbosity is 2, then queries in all tests are\noutput.
Django may, from time to time, extend the capabilities of the test runner\nby adding new arguments. The **kwargs declaration allows for this\nexpansion. If you subclass DiscoverRunner or write your own test\nrunner, ensure it accepts **kwargs.
Your test runner may also define additional command-line options.\nCreate or override an add_arguments(cls, parser) class method and add\ncustom arguments by calling parser.add_argument() inside the method, so\nthat the test command will be able to use those arguments.
The class used to build the test suite. By default it is set to\nunittest.TestSuite. This can be overridden if you wish to implement\ndifferent logic for collecting tests.
This is the class of the low-level test runner which is used to execute\nthe individual tests and format the results. By default it is set to\nunittest.TextTestRunner. Despite the unfortunate similarity in\nnaming conventions, this is not the same type of class as\nDiscoverRunner, which covers a broader set of responsibilities. You\ncan override this attribute to modify the way tests are run and reported.
This is the class that loads tests, whether from TestCases or modules or\notherwise and bundles them into test suites for the runner to execute.\nBy default it is set to unittest.defaultTestLoader. You can override\nthis attribute if your tests are going to be loaded in unusual ways.
Run the test suite.
\ntest_labels allows you to specify which tests to run and supports\nseveral formats (see DiscoverRunner.build_suite() for a list of\nsupported formats).
extra_tests is a list of extra TestCase instances to add to the\nsuite that is executed by the test runner. These extra tests are run\nin addition to those discovered in the modules listed in test_labels.
This method should return the number of tests that failed.
\nOverride this class method to add custom arguments accepted by the\ntest management command. See\nargparse.ArgumentParser.add_argument() for details about adding\narguments to a parser.
Sets up the test environment by calling\nsetup_test_environment() and setting\nDEBUG to self.debug_mode (defaults to False).
Constructs a test suite that matches the test labels provided.
\ntest_labels is a list of strings describing the tests to be run. A test\nlabel can take one of four forms:
path.to.test_module.TestCase.test_method – Run a single test method\nin a test case.
path.to.test_module.TestCase – Run all the test methods in a test\ncase.
path.to.module – Search for and run all tests in the named Python\npackage or module.
path/to/directory – Search for and run all tests below the named\ndirectory.
If test_labels has a value of None, the test runner will search for\ntests in all files below the current directory whose names match its\npattern (see above).
extra_tests is a list of extra TestCase instances to add to the\nsuite that is executed by the test runner. These extra tests are run\nin addition to those discovered in the modules listed in test_labels.
Returns a TestSuite instance ready to be run.
Creates the test databases by calling\nsetup_databases().
Runs the system checks.
\nRuns the test suite.
\nReturns the result produced by the running the test suite.
\nReturns the keyword arguments to instantiate the\nDiscoverRunner.test_runner with.
Destroys the test databases, restoring pre-test conditions by calling\nteardown_databases().
Restores the pre-test environment.
\nComputes and returns a return code based on a test suite, and the result\nfrom that test suite.
\ndjango.test.utilsLink to this heading#To assist in the creation of your own test runner, Django provides a number of\nutility methods in the django.test.utils module.
Performs global pre-test setup, such as installing instrumentation for the\ntemplate rendering system and setting up the dummy email outbox.
\nIf debug isn’t None, the DEBUG setting is updated to its\nvalue.
Performs global post-test teardown, such as removing instrumentation from\nthe template system and restoring normal email services.
\nCreates the test databases.
\nReturns a data structure that provides enough detail to undo the changes\nthat have been made. This data will be provided to the\nteardown_databases() function at the conclusion of testing.
Destroys the test databases, restoring pre-test conditions.
\nold_config is a data structure defining the changes in the database\nconfiguration that need to be reversed. It’s the return value of the\nsetup_databases() method.
django.db.connection.creationLink to this heading#The creation module of the database backend also provides some utilities that\ncan be useful during testing.
\nCreates a new test database and runs migrate against it.
verbosity has the same behavior as in run_tests().
autoclobber describes the behavior that will occur if a\ndatabase with the same name as the test database is discovered:
If autoclobber is False, the user will be asked to\napprove destroying the existing database. sys.exit is\ncalled if the user does not approve.
If autoclobber is True, the database will be destroyed\nwithout consulting the user.
serialize determines if Django serializes the database into an\nin-memory JSON string before running tests (used to restore the database\nstate between tests if you don’t have transactions). You can set this to\nFalse to speed up creation time if you don’t have any test classes\nwith serialized_rollback=True.
If you are using the default test runner, you can control this with the\nthe SERIALIZE entry in the TEST dictionary.
keepdb determines if the test run should use an existing\ndatabase, or create a new one. If True, the existing\ndatabase will be used, or created if not present. If False,\na new database will be created, prompting the user to remove\nthe existing one, if present.
Returns the name of the test database that it created.
\ncreate_test_db() has the side effect of modifying the value of\nNAME in DATABASES to match the name of the test\ndatabase.
Destroys the database whose name is the value of NAME in\nDATABASES, and sets NAME to the value of\nold_database_name.
The verbosity argument has the same behavior as for\nDiscoverRunner.
If the keepdb argument is True, then the connection to the\ndatabase will be closed, but the database will not be destroyed.
coverage.pyLink to this heading#Code coverage describes how much source code has been tested. It shows which\nparts of your code are being exercised by tests and which are not. It’s an\nimportant part of testing applications, so it’s strongly recommended to check\nthe coverage of your tests.
\nDjango can be easily integrated with coverage.py, a tool for measuring code\ncoverage of Python programs. First, install coverage.py. Next, run the\nfollowing from your project folder containing manage.py:
coverage run --source='.' manage.py test myapp\nThis runs your tests and collects coverage data of the executed files in your\nproject. You can see a report of this data by typing following command:
\ncoverage report\nNote that some Django code was executed while running tests, but it is not\nlisted here because of the source flag passed to the previous command.
For more options like annotated HTML listings detailing missed lines, see the\ncoverage.py docs.
\n