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 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\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 dinyalakan sebelum setiap percobaan membuat jenis-jenis isi dan perizinan untuk setiap model dalam aplikasi tersedia, dalam kasus mereka hilang.
Setelah setiap percobaan, Django mengkosongkan hanya tabel-tabel sesuai ke model dalam aplikasi tersedia. Bagaimanapun, pada tingkat basisdata, pemotongan mungkin menurun pada model-model terkait dalam aplikasi tidak tersedia. Lebih lanjut post_migrate tidak dinyalakan. Itu akan dinyalakan oleh TransactionTestCase selanjutnya, setelah kumpulan benar dari aplikasi-aplikasi dipilih.
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 adalah wajib dalam deretan percobaan Django sendiri.
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 hardcode 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\nMari kita lihat didalam sepasang berkas-berkas tersebut:
\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))\nIni adalah tulisan yang anda minta menjalankan deretan percobaan. itu menyetel lingkungan Django, membuat basisdata percobaan dan menjalankan percobaan.
\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]\nBerkas ini mengandung Django settings dibutuhkan untuk menjalankan aplikasi percobaan anda.
\nKembali, ini adalah cotoh minimal; percobaan anda mungkin membutuhkan pengaturan tambahan untuk berjalan.
\nKarena paket tests disertakan dalam INSTALLED_APPS saat menjalankan pengujian, anda dapat menentukan model khusus pengujian dalam berkas models.py.
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.
Ketika anda menjalankan ./manage.py test, Django melihat pengaturan TEST_RUNNER untuk menentukan apa yang harus dilakukan. Secara awalan, TEST_RUNNER menunjuk ke 'django.test.runner.DiscoverRunner'. Kelas ini mendefinisikan perilaku pengujian Django awalan. Perilaku ini melibatkan:
Performing global pre-test setup.
Mencari pengujian di berkas apa pun di bawah direktori saat ini yang namanya cocok dengan pola test*.py.
Membuat basisdata percobaan.
Running migrate to install models and initial data into the test\ndatabases.
Menjalankan system checks.
Menjalankan percobaan yang ditemukan.
Menghancurkan basisdata percobaan.
Performing global post-test teardown.
Jika Anda mendefinisikan kelas runner pengujian anda sendiri dan titik TEST_RUNNER pada kelas itu, Django akan mengeksekusi runner pengujian anda setiap kali anda menjalankan ./manage.py test. Dengan cara ini, dimungkinkan untuk menggunakan kerangka pengujian yang dapat dijalankan dari kode Python, atau untuk merubah proses eksekusi pengujian Django untuk memenuhi persyaratan pengujian apa pun yang mungkin anda miliki.
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 dapat digunakan untuk menentukan direktori yang berisi modul Python tingkat atas anda. Biasanya Django dapat mengetahui ini secara otomatis, jadi tidak perlu menentukan opsi ini. Jika ditentukan, biasanya ini adalah direktori yang berisi file manage.py anda.
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 case classes than configured processes, Django will reduce the\nnumber of processes accordingly. Each process gets its own database. This\noption requires the third-party tblib package to display tracebacks\ncorrectly.
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.
durations will show a list of the N slowest test cases. Setting this\noption to 0 will result in the duration for all tests being shown.
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.
Jalankan deretan percobaan.
\ntest_labels allows you to specify which tests to run and supports\nseveral formats (see DiscoverRunner.build_suite() for a list of\nsupported formats).
Cara ini harus mengembalikan angka dari percobaan yang gagal.
\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).
Membangun rangkaian percobaan yang cocok dengan label percobaan disediakan.
\ntest_labels adalah daftar dari string menggambarkan percobaan untuk dijalankan. Sebuah label percobaan dapat mengambil satu dari empat bentuk:
path.to.test_module.TestCase.test_method -- Run a single test method\nin a test case class.
path.to.test_module.TestCase -- Jalankan semua metode percobaan dalam kasus percobaan.
path.to.module -- Cari dan jalankan semua percobaan yang bernama paket atau modul Python.
path/to/directory -- Cari dan jalankan semua percobaan dibawan direktori dinamai.
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).
Mengembalikan sebuah instance TestSuite untuk dijalankan.
Membuat basisdata percobaan dengan memanggil setup_databases().
Runs the system checks on the test databases.
Jalankan deretan percobaan.
\nMengembalikan hasil dihasilkan dari menjalankan deretan percobaan.
\nMengembalikan argumen kata kunci untuk menginstansiasi dengan DiscoverRunner.test_runner.
Menghancurkan basisdata percobaan, menyimpan kembali keadaan pra-percobaan dengan memanggil teardown_databases().
Menyimpan kembali lingkungan pra-percobaan.
\nMenghitung dan mengembalikan kode balikan berdasarkan pada deretan percobaan, dan hasil dari deretan percobaan itu.
\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 to this heading#Untuk membantu dalam pembuatan dari pejalan percobaan anda sendiri, Django menyediakan sejumlah metode utilitas dalam modul django.test.utils.
Performs global pre-test setup, such as installing instrumentation for the\ntemplate rendering system and setting up the dummy email outbox.
\nJika debug bukan None, pengaturan DEBUG diperbaharui pada nilainya.
Performs global post-test teardown, such as removing instrumentation from\nthe template system and restoring normal email services.
\nMembuat basisdata percobaan.
\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.
Menghancurkan basisdata percobaan, menyimpan kembali keadaan pra-pengujian.
\nold_config adalah struktur data menentukan peribahan dalam konfigurasi basisdata yang butuh di balik. Nilai kembaliannya dari metode setup_databases().
The creation module of the database backend also provides some utilities that\ncan be useful during testing.
\nMembuat percobaan basisdata baru dan menjalankan migrate terhadapnya.
verbosity mempunyai perilaku sama seperti dalam 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.
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.
Mengembalikan nama dari basisdata percobaan yang dia buat.
\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.
Serializes the database into an in-memory JSON string that can be used to\nrestore the database state between tests if the backend doesn't support\ntransactions or if your suite contains test classes with\nserialized_rollback=True enabled.
\nThis function should only be called once all test databases have been\ncreated as the serialization process could result in queries against\nnon-test databases depending on your\nrouting configuration.
\ncoverage.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 dapat dengan mudah diintegrasikan dengan coverage.py, alat untuk mengukur cakupan kode program Python. Pertama, instal coverage. Selanjutnya, jalankan perintah berikut dari folder proyek anda yang berisi 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\nCatat bahwa beberapa kode Django telah dijalankan selagi menjalankan percobaan, tetapi itu tidak didaftarkan disini karena bendera source dilewatkan ke perintah sebelumnya.
Untuk piihan lainnya seperti cantuman HTML beranotasi yang memerinci baris yang terlewat, lihat dokumen coverage.py.
\n