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 RequestFactory, TestCase\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 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 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 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]\nBerkas ini mengandung Django settings dibutuhkan untuk menjalankan aplikasi percobaan anda.
\nKembali, ini adalah cotoh minimal; percobaan anda mungkin membutuhkan pengaturan tambahan untuk berjalan.
\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.
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.
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.
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).
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.
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 -- Jalankan metode percobaan tunggal dalam kasus percobaan.
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).
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.
Mengembalikan sebuah instance TestSuite untuk dijalankan.
Membuat basisdata percobaan dengan memanggil setup_databases().
Menjalankan system checks.
\nJalankan 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.
\ndjango.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.
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.
serialize menentukan jika Django serialkan basisdata menjadi sebuah string JSON dalam-memori sebelum menjalankan percobaan (digunakan untuk menyimpan kembali keadaan basisdata jika anda tidak mempunyai transaksi). Anda dapat menyetel ini menjadi False untuk mempercepat waktu pembuatan jika anda tidak mempunyai kelas-kelas percobaan dengan serialized_rollback=True 1.
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.
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.
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\nCatat bahwa beberapa kode Django telah dijalankan selagi menjalankan percobaan, tetapi itu tidak didaftarkan disini karena bendera source dilewatkan ke perintah sebelumnya.
For more options like annotated HTML listings detailing missed lines, see the\ncoverage.py docs.
\n