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 unit test using the request factory:
\nfrom django.contrib.auth.models import AnonymousUser, User\nfrom django.test import RequestFactory, TestCase\n\nfrom .views import MyView, my_view\n\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\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)\nRequestFactory creates WSGI-like requests. If you want to create ASGI-like\nrequests, including having a correct ASGI scope, you can instead use\ndjango.test.AsyncRequestFactory.
This class is directly API-compatible with RequestFactory, with the only\ndifference being that it returns ASGIRequest instances rather than\nWSGIRequest instances. All of its methods are still synchronous callables.
Arbitrary keyword arguments in defaults are added directly into the ASGI\nscope.
In order to test class-based views outside of the request/response cycle you\nmust ensure that they are configured correctly, by calling\nsetup() after instantiation.
For example, assuming the following class-based view:
\nviews.pyfrom django.views.generic import TemplateView\n\n\nclass HomeView(TemplateView):\n template_name = "myapp/home.html"\n\n def get_context_data(self, **kwargs):\n kwargs["environment"] = "Production"\n return super().get_context_data(**kwargs)\nYou may directly test the get_context_data() method by first instantiating\nthe view, then passing a request to setup(), before proceeding with\nyour test’s code:
tests.pyfrom django.test import RequestFactory, TestCase\nfrom .views import HomeView\n\n\nclass HomePageTest(TestCase):\n def test_environment_set_in_context(self):\n request = RequestFactory().get("/")\n view = HomeView()\n view.setup(request)\n\n context = view.get_context_data()\n self.assertIn("environment", context)\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 option to do so is to add the hosts to your settings file. For\nexample, the test suite for docs.djangoproject.com includes the following:
\nfrom django.test import TestCase\n\n\nclass SearchFormTestCase(TestCase):\n def test_empty_get(self):\n response = self.client.get(\n "/en/dev/search/",\n headers={"host": "docs.djangoproject.dev:8000"},\n )\n self.assertEqual(response.status_code, 200)\nand the settings file includes a list of the domains supported by the project:
\nALLOWED_HOSTS = ["www.djangoproject.dev", "docs.djangoproject.dev", ...]\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\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. As this depends on transactions, the tests must use\nTransactionTestCase instead of\nTestCase.
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 para este cabeçalho#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\nrecreates one content type and four 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 a relatively expensive database operation.
If you have test classes that cannot be run in parallel (e.g. because they\nshare a common resource), you can use django.test.testcases.SerializeMixin\nto run them sequentially. This mixin uses a filesystem lockfile.
For example, you can use __file__ to determine that all test classes in the\nsame file that inherit from SerializeMixin will run sequentially:
import os\n\nfrom django.test import TestCase\nfrom django.test.testcases import SerializeMixin\n\n\nclass ImageTestCaseMixin(SerializeMixin):\n lockfile = __file__\n\n def setUp(self):\n self.filename = os.path.join(temp_storage_dir, "my_file.png")\n self.file = create_file(self.filename)\n\n\nclass RemoveImageTests(ImageTestCaseMixin, TestCase):\n def test_remove_image(self):\n os.remove(self.filename)\n self.assertFalse(os.path.exists(self.filename))\n\n\nclass ResizeImageTests(ImageTestCaseMixin, TestCase):\n def test_resize_image(self):\n resize_image(self.file, (48, 48))\n self.assertEqual(get_image_size(self.file), (48, 48))\nIf 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 by run_tests() to set up, execute\nand 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. This option can be used in conjunction\nwith --shuffle to reverse the order for a particular random seed.
debug_mode specifies what the DEBUG setting should be\nset to prior to running tests.
parallel specifies the number of processes. If parallel is greater\nthan 1, the test suite will run in parallel processes. If there are\nfewer test cases than configured processes, Django will reduce the number\nof processes accordingly. Each process gets its own database. This option\nrequires the third-party tblib package to display tracebacks correctly.
tags can be used to specify a set of tags for filtering tests. May be combined with exclude_tags.
exclude_tags can be used to specify a set of\ntags for excluding tests. May be combined\nwith tags.
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.
test_name_patterns can be used to specify a set of patterns for\nfiltering test methods and classes by their names.
If pdb is True, a debugger (pdb or ipdb) will be spawned at\neach test error or failure.
If buffer is True, outputs from passing tests will be discarded.
If enable_faulthandler is True, faulthandler will be\nenabled.
If timing is True, test timings, including database setup and total\nrun time, will be shown.
If shuffle is an integer, test cases will be shuffled in a random order\nprior to execution, using the integer as a random seed. If shuffle is\nNone, the seed will be generated randomly. In both cases, the seed will\nbe logged and set to self.shuffle_seed prior to running tests. This\noption can be used to help detect tests that aren’t properly isolated.\nGrouping by test class is preserved when using this\noption.
logger can be used to pass a Python Logger object.\nIf provided, the logger will be used to log messages instead of printing to\nthe console. The logger object will respect its logging level rather than\nthe verbosity.
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).
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).
Returns a TestSuite instance ready to be run.
Creates the test databases by calling\nsetup_databases().
Runs the system checks on the test databases.
Runs 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.
\nIf a logger is set, logs the message at the given integer\nlogging level (e.g. logging.DEBUG, logging.INFO, or\nlogging.WARNING). Otherwise, the message is printed to the console,\nrespecting the current verbosity. For example, no message will be\nprinted if the verbosity is 0, INFO and above will be printed if\nthe verbosity is at least 1, and DEBUG will be printed if it is at\nleast 2. The level defaults to logging.INFO.
django.test.utilsLink para este cabeçalho#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.
The aliases argument determines which DATABASES aliases test\ndatabases should be set up for. If it’s not provided, it defaults to all of\nDATABASES aliases.
The serialized_aliases argument determines what subset of aliases\ntest databases should have their state serialized to allow usage of the\nserialized_rollback feature. If\nit’s not provided, it defaults to aliases.
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 para este cabeçalho#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 para este cabeçalho#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. 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