Django datang dengan deretan percobaan dia sendiri, di pelipat tests dari kode dasar. Itu kebijakan kami untuk memastikan semua percobaan selalu lolos.
Kami menghargai apapun dan semua bantuan pada deretan percobaan!
\nPercobaan Django semua menggunakan infrastruktur percobaan yang dikirim dengan Django untuk aplikasi percobaan. Lihat Menulis dan menjalankan percobaan untuk sebuah penjelasan bagaimana menulis percobaan baru.
\nPertama, fork Django on GitHub.
\nKedua, buat dan aktifkan lingkungan maya. Jika anda tidak akrab dengan bagaimana melakukan itu, baca contributing tutorial kami.
\nSelanjutnya, kloning cabang anda, pasang beberapa persyaratan, dan jalankan percobaan:
\nLinux / macOS
$ git clone https://github.com/YourGitHubName/django.git django-repo\n$ cd django-repo/tests\n$ python -m pip install -e ..\n$ python -m pip install -r requirements/py3.txt\n$ ./runtests.py\nWindows
...\\> git clone https://github.com/YourGitHubName/django.git django-repo\n...\\> cd django-repo\\tests\n...\\> py -m pip install -e ..\n...\\> py -m pip install -r requirements\\py3.txt\n...\\> runtests.py \nInstalling the requirements will likely require some operating system packages\nthat your computer doesn't have installed. You can usually figure out which\npackage to install by doing a web search for the last line or so of the error\nmessage. Try adding your operating system to the search query if needed.
\nIf you have trouble installing an optional test dependency, you can skip that\ndependency locally. For example, if installing pylibmc fails, comment out\nits line in requirements/py3.txt and continue with ./runtests.py.\nTests that require pylibmc will be skipped automatically. See\nMenjalankan semua percobaan for details on installing the optional\ntest dependencies.
Menjalankan percobaan membutuhkan modul pengaturan Django yang menentukan basisdata yang digunakan. Untuk membantu anda memulai, Django menyediakan dan menggunakan contoh modul pengaturan yang menggunakan basisdata SQLite. Lihat Gunakan modul pengaturan lain untuk mempelajari bagaimana menggunakan modul pengaturan berbeda untuk menjalankan percobaan dengan basisdata berbeda.
\nMempunyai masalah? Lihat Menyelesaikan masalah untuk beberapa masalah umum.
\ntoxLink to this heading#Tox is a tool for running tests in different virtual\nenvironments. Django includes a basic tox.ini that automates some checks\nthat our build server performs on pull requests. To run the unit tests and\nother checks (such as import sorting, the\ndocumentation spelling checker, and\ncode formatting), install and run the tox\ncommand from any place in the Django source tree:
Linux / macOS
$ python -m pip install tox\n$ tox\nWindows
...\\> py -m pip install tox\n...\\> tox\nBy default, tox runs the test suite with the bundled test settings file for\nSQLite, black, blacken-docs, flake8, isort, lint-docs,\nzizmor, and the documentation spelling checker. In addition to the system\ndependencies noted elsewhere in this documentation, the command python3\nmust be on your path and linked to the appropriate version of Python. A list of\ndefault environments can be seen as follows:
Linux / macOS
$ tox -l\npy3\nblack\nblacken-docs\nflake8>=3.7.0\ndocs\nisort>=7.0.0\nlint-docs\nzizmor>=1.16.3\nWindows
...\\> tox -l\npy3\nblack\nblacken-docs\nflake8>=3.7.0\ndocs\nisort>=7.0.0\nlint-docs\nzizmor>=1.16.3\nIn addition to the default environments, tox supports running unit tests\nfor other versions of Python and other database backends. Since Django's test\nsuite doesn't bundle a settings file for database backends other than SQLite,\nhowever, you must create and provide your own test settings. For example, to run the tests on Python 3.12\nusing PostgreSQL:
Linux / macOS
$ tox -e py312-postgres -- --settings=my_postgres_settings\nWindows
...\\> tox -e py312-postgres -- --settings=my_postgres_settings\nThis command sets up a Python 3.12 virtual environment, installs Django's\ntest suite dependencies (including those for PostgreSQL), and calls\nruntests.py with the supplied arguments (in this case,\n--settings=my_postgres_settings).
Sisa dari dokumentasi ini menunjukkan perintah untuk menjalankan percobaan tanpa tox, bagaimanapun, pilihan apapun dilewatkan ke runtests.py dapat juga dilewatkan ke tox dengan menaruh di awalan daftar argumen dengan --, seperti diatas.
Tox also respects the DJANGO_SETTINGS_MODULE environment\nvariable, if set. For example, the following is equivalent to the command\nabove:
$ DJANGO_SETTINGS_MODULE=my_postgres_settings tox -e py312-postgres\nPengguna Windows harus menggunakan:
\n...\\> set DJANGO_SETTINGS_MODULE=my_postgres_settings\n...\\> tox -e py312-postgres\nDjango includes a set of JavaScript unit tests for\nfunctions in certain contrib apps. The JavaScript tests aren't run by default\nusing tox because they require Node.js to be installed and aren't\nnecessary for the majority of patches. To run the JavaScript tests using\ntox:
Linux / macOS
$ tox -e javascript\nWindows
...\\> tox -e javascript\nPerintah ini menjalankan npm install untuk memastikan persyaratan percobaan terperbaharui dan kemudian menjalankan npm test.
django-docker-boxLink to this heading#django-docker-box mengizinkan anda menjalankan deretan percobaan terhadap semua basisdata yang didukung dan versi python. Lihat halaman proyek django-docker-box untuk pemasangan dan petunjuk penggunaan.
\npengaturan lainLink to this heading#The included settings module (tests/test_sqlite.py) allows you to run the\ntest suite using SQLite. If you want to run the tests using a different\ndatabase, you'll need to define your own settings file. Some tests, such as\nthose for contrib.postgres, are specific to a particular database backend\nand will be skipped if run with a different backend. Some tests are skipped or\nexpected failures on a particular database backend (see\nDatabaseFeatures.django_test_skips and\nDatabaseFeatures.django_test_expected_failures on each backend).
To run the tests with different settings, ensure that the module is on your\nPYTHONPATH and pass the module with --settings.
Pengaturan DATABASES dalam modul pengaturan percobaan apapun butuh menentukan dua basisdata:
Basisdata default. Basisdata ini harus menggunakan backend yang anda ingin menggunakan untuk percobaan utama.
Sebuah basisdata dengan nama lain other. Basisdata other digunakan untuk mencoba permintaan itu dapat dialihkan ke basisdata berbeda. Basisdata ini harus menggunakan backend sama seperti default, dan itu harus mempunyai nama berbeda.
Jika anda menggunakan backend yang bukan SQLite, anda akan butuh menyediakan rincian lain untuk setiap basisdata:
\nPilihan USER butuh menentukan akun pengguna yang ada ntuk basisdata. Bahwa pengguna butuh perizinan untuk menjalankan CREATE DATABASE sehingga basisdata percobaan dapat dibuat.
Pilihan PASSWORD butuh disediakan sandi untuk the USER yang telah ditentukan.
Basisdata percobaan mendapatkan nama-nama mereka dengan mengawali test_ pada nilai dari pengaturan NAME untuk basisdata ditentukan di DATABASES. Basisdata percobaan ini dihapus ketika percobaan selesai.
Anda akan juga butuh memastikan bahwa basisdata anda menggunakan UTF-8 sebagai kumpulan karakter awal. Jika peladen basisdata anda tidak menggunakan UTF-8 sebagai kumpulan karakter awal, anda akan butuh menyertakan sebuah nilai untuk CHARSET di kamus pengaturan untuk basisdata yang berlaku.
Deretan percobaan keseluruhan Django perlu waktu untuk berjalan, dan menjalankan setiap percobaan tunggal yang dapat berulang jika, katakan, anda cukup menambahkan percobaan pada Django yang anda ingin jalankan secara cepat tanpa menjalankan yang lainnya. Anda dapat menjalankan subkumpulan dari satuan percobaan dengan menambahkan nama-nama dari modul percobaan pada runtests.py di baris perintah.
Sebagai contoh, jika anda ingin menjalankan percobaan hanya untuk hubugnan umum dan internasionalisasi, ketik:
\nLinux / macOS
$ ./runtests.py --settings=path.to.settings generic_relations i18n\nWindows
...\\> runtests.py --settings=path.to.settings generic_relations i18n\nBagaimana anda menemukan nama-nama dari percobaan perorangan? Lihat di tests/ — setiap nama pelipat ada nama dari percobaan.
Jika anda hanya ingin menjalankan hanya kelas tertentu dari percobaan, anda dapat menentukan daftar jalur pada masing-masing kelas percobaan. Sebgai contoh, untuk menjalankan TranslationTests dari modul i18n, ketik:
Linux / macOS
$ ./runtests.py --settings=path.to.settings i18n.tests.TranslationTests\nWindows
...\\> runtests.py --settings=path.to.settings i18n.tests.TranslationTests\nMelampaui itu, anda dapat menentukan metode percobaan sendiri seperti ini:
\nLinux / macOS
$ ./runtests.py --settings=path.to.settings i18n.tests.TranslationTests.test_lazy_objects\nWindows
...\\> runtests.py --settings=path.to.settings i18n.tests.TranslationTests.test_lazy_objects\nAnda dapat menjalankan percobaan dimulai pada menentukan modul tingkat-atas dengan pilihan --start-at. Sebagai contoh:
Linux / macOS
$ ./runtests.py --start-at=wsgi\nWindows
...\\> runtests.py --start-at=wsgi\nAnda dapat juga menjalankan percobaan dimulai setelah modul tingkat-atas ditentukan dengan pilihan --start-after. Sebagai contoh:
Linux / macOS
$ ./runtests.py --start-after=wsgi\nWindows
...\\> runtests.py --start-after=wsgi\nCatat bahwa pilihan --reverse tidak berpengaruh pada pilihan --start-at atau --start-after. Bahkan pilihan ini tidak dapat digunakan dengan label percobaan.
Some tests require Selenium and a web browser. To run these tests, you must\ninstall the selenium package and run the tests with the\n--selenium=<BROWSERS> option. For example, if you have Firefox and Google\nChrome installed:
Linux / macOS
$ ./runtests.py --selenium=firefox,chrome\nWindows
...\\> runtests.py --selenium=firefox,chrome\nLihat paket selenium.webdriver untuk daftar perambah tersedia.
\nMenentukan --selenium otomatis menyetel --tags=selenium untuk berjalan hanya percobaan yang membutuhkan selenium.
Beberapa peramban (yaitu Chrome atau Firefox) mendukung percobaan tanpa kepala, yang dapat lebih cepat dan lebih stabil. Tambah pilihan --headless untuk mengaktifkan suasana ini.
For testing changes to the admin UI, the selenium tests can be run with the\n--screenshots option enabled. Screenshots will be saved to the\ntests/screenshots/ directory.
To define when screenshots should be taken during a selenium test, the test\nclass must use the @django.test.selenium.screenshot_cases decorator with a\nlist of supported screenshot types ("desktop_size", "mobile_size",\n"small_screen_size", "rtl", "dark", and "high_contrast"). It\ncan then call self.take_screenshot("unique-screenshot-name") at the desired\npoint to generate the screenshots. For example:
from django.test.selenium import SeleniumTestCase, screenshot_cases\nfrom django.urls import reverse\n\n\nclass SeleniumTests(SeleniumTestCase):\n @screenshot_cases(["desktop_size", "mobile_size", "rtl", "dark", "high_contrast"])\n def test_login_button_centered(self):\n self.selenium.get(self.live_server_url + reverse("admin:login"))\n self.take_screenshot("login")\n ...\nThis generates multiple screenshots of the login page - one for a desktop\nscreen, one for a mobile screen, one for right-to-left languages on desktop,\none for the dark mode on desktop, and one for high contrast mode on desktop\nwhen using chrome.
\nJika anda ingin menjalankan deretan lengkap dari percobaan, anda akan butuh memasang sejumlah ketergantungan:
\naiosmtpd 1.4.5+
argon2-cffi 23.1.0+
asgiref 3.9.1+ (required)
bcrypt 4.1.1+
colorama 0.4.6+
docutils 0.22+
geoip2 4.8.0+
Jinja2 2.11+
numpy 1.26.0+
Pillow 10.1.0+
PyYAML 6.0.2+
redis 5.1.0+
pymemcache, plus a supported Python binding
selenium 4.23.0+
sqlparse 0.5.0+ (required)
tblib 3.0.0+
You can find these dependencies in pip requirements files inside the\ntests/requirements directory of the Django source tree and install them\nlike so:
Linux / macOS
$ python -m pip install -r tests/requirements/py3.txt\nWindows
...\\> py -m pip install -r tests\\requirements\\py3.txt\nJika anda mengalami sebuah kesalahan selama pemasangan, sisem anda mungkin kehilangan ketergantungan untuk satu atau lebih paket Python. Obrolkan dokumentasi paket yang gagal atau cari di jaringan dengan pesan kesalahan yang anda alami.
\nAnda dapat juga memasang pencocok basisdata dari pilihan anda menggunakan oracle.txt`, mysql.txt, atau postgres.txt.
If you want to test the memcached or Redis cache backends, you'll also need to\ndefine a CACHES setting that points at your memcached or Redis\ninstance respectively.
To run the GeoDjango tests, you will need to set up a spatial database\nand install the Geospatial libraries.
\nMasing-masing ketergantungan ini adalah pilihan. Jika anda kehilangan salah satu dari mereka, percobaan terkait akan dilewati.
\nTo run some of the autoreload tests, you'll need to install the\nWatchman service.
\nPembantu mendorong menjalankan cakupan pada deretan percobaan untuk mencirikan kawasan yang butuh percobaan tambahan. Pemasangan alat cakupan dan penggunaan digambarkan dalam testing code coverage.
\nTo run coverage on the Django test suite using the standard test settings:
\nLinux / macOS
$ coverage run ./runtests.py --settings=test_sqlite\nWindows
...\\> coverage run runtests.py --settings=test_sqlite\nAfter running coverage, combine all coverage statistics by running:
\nLinux / macOS
$ coverage combine\nWindows
...\\> coverage combine\nSetelah itu bangkitkan laporan html dengan menjalankan:
\nLinux / macOS
$ coverage html\nWindows
...\\> coverage html\nKetika menjalankan cakupan untuk percobaan Django, pengaturan .coveragerc yang disertakan menentukan coverage_html sebagai pelipat keluaran untuk laporan dan juga mengecualikan beberapa pelipat tidak terkait pada hasil (kode percobaan atau kode dikecualikan disertakan di Django).
Django's continuous integration (CI) system automatically runs code coverage\nanalysis on pull requests and posts a comment with a diff coverage report. This\nhelps reviewers see which lines in the changed code are covered by tests.
\nWhat the coverage report shows:
\nThe coverage report posted on pull requests uses diff-cover to analyze only\nthe lines that were changed or added in the PR. It shows:
\nLines that are covered by tests (✓)
Lines that are not covered by tests (✗)
Lines that cannot be covered (e.g., comments, blank lines)
Important limitations:
\nWhen reviewing coverage reports on pull requests, keep these limitations in\nmind:
\nDatabase-specific code: The CI coverage job runs tests using SQLite on\nWindows. Code paths specific to other databases (PostgreSQL, MySQL, Oracle)\nwill appear as "not covered" even if database-specific tests exist. This is\nexpected and acceptable.
Platform-specific code: Similarly, code that only runs on certain\noperating systems (Linux, macOS) will appear as not covered when run on\nWindows.
Coverage doesn't equal quality: A line being "covered" only means it was\nexecuted during tests. It doesn't guarantee the line is well-tested or that\nall edge cases are handled. During review, assess test quality beyond just\ncoverage numbers.
Missing coverage should be considered a warning rather than a blocker and\nshould be evaluated in context.
\nTests for contrib apps can be found in the tests/ directory,\ntypically under <app_name>_tests. For example, tests for contrib.auth\nare located in tests/auth_tests.
mainLink to this heading#Pastikan anda memiliki titik terbitan terakhir dari supported Python version, sejak sering ada kesalahan dalam versi sebelumnya yang mungkin menyebabkan deretan percobaan gagal atau menggantung.
\nOn macOS (High Sierra and newer versions), you might see this message\nlogged, after which the tests hang:
\nobjc[42074]: +[__NSPlaceholderDate initialize] may have been in progress in\nanother thread when fork() was called.\nUntuk menghindari ini setel variabel lingkungan OBJC_DISABLE_INITIALIZE_FORK_SAFETY, sebagai contoh:
$ OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES ./runtests.py\nAtau tambah export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES ke berkas awal shell anda (contoh ~/.profile).
UnicodeEncodeErrorLink to this heading#Jika paket locales tidak terpasang, beberapa percobaan akan gagal dengan UnicodeEncodeError.
Anda dapat menyelesaikan ini pada sistem berdasarkan-Debian, sebagai contoh, dengan menjalankan:
\n$ apt-get install locales\n$ dpkg-reconfigure locales\nAnda dapat mengatasi ini untuk sistem macOS dengan mengkonfigurasi lokal shell anda:
\n$ export LANG="en_US.UTF-8"\n$ export LC_ALL="en_US.UTF-8"\nJalankan perintah locale untuk menegaskan perubahan. Pilihannya, tambah perintah ekpos tersebut pada berkas awalan shell anda (sebagai contoh ~/.bashrc untuk Bash) untuk menghindari mengetik kembali mereka.
Dalam hal sebuah percobaan lulus ketika berjalan di pemisahan tetapi gagal dalam deretan keseluruhan, kami mempunyai beberapa alat untuk membantu menganalisa masalah.
\nPilihan --bisect dari runtests.py akan menjalankan percobaan kegagalan selama separuh kumpulan percobaan yang dijalankan bersama-sama pada setiap putaran, sering membuatnya memungkinkan untuk mencirikan sejumlah kecil dari percobaan yang mungkin terkait terhadap kegagalan.
Sebagai contoh, misalkan bahwa percobaan gagal yang berkerja pada miliknya sendiri adalah ModelTest.test_eq, kemudian menggunakan:
Linux / macOS
$ ./runtests.py --bisect basic.tests.ModelTest.test_eq\nWindows
...\\> runtests.py --bisect basic.tests.ModelTest.test_eq\nakan mencoba menentukan percobaan yang mencampuri dengan satu yang diberikan. Pertama, percobaan berjalan dengan babak pertama dari deretan percobaan. Jika kegagalan muncul, babak pertama dari deretan percobaan dipisah dalam dua kelompok dan setiap kelompok berjalan dengan percobaan yang ditentukan. Jika tidak ada kegagalan dengan babak pertama dari deretan percobaan, babak kedua dari deretan percobaan berjalan dengan percobaan yang ditentukan dan dipisah dengan benar seperti digambarkan di awal. Pengolahan berulang sampai kumpulan percobaan kegagalan kecil.
\nPilihan --pair menjalankan percobaan diberikan bersama setiap percobaan lain dari deretan, membiarkan anda memeriksa jika percobaan lain mempunyai pengaruh-samping yang menyebabkan kegagalan. Jadi:
Linux / macOS
$ ./runtests.py --pair basic.tests.ModelTest.test_eq\nWindows
...\\> runtests.py --pair basic.tests.ModelTest.test_eq\nakan memperbaiki test_eq dengan setiap label percobaan.
Dengan kedua --bisect dan --pair, jika anda sudah menduga kasus mana yang mungkin bertanggung jawab terhadap kegagalan, anda mungkin membatasi percobaan pada analisa-silang dengan specifying further test labels setelah yang pertama:
Linux / macOS
$ ./runtests.py --pair basic.tests.ModelTest.test_eq queries transactions\nWindows
...\\> runtests.py --pair basic.tests.ModelTest.test_eq queries transactions\nYou can also try running any set of tests in a random or reverse order using\nthe --shuffle and --reverse options. This can help verify that\nexecuting tests in a different order does not cause any trouble:
Linux / macOS
$ ./runtests.py basic --shuffle\n$ ./runtests.py basic --reverse\nWindows
...\\> runtests.py basic --shuffle\n...\\> runtests.py basic --reverse\nJika anda berharap menguji SQL yang sedang berjalan dalam kegagalan percobaan, anda dapat menyalakan SQL logging menggunakan pilihan --debug-sql. Jika anda menggabungkan ini dengan --verbosity=2, semua permintaan SQL akan mengeluarkan:
Linux / macOS
$ ./runtests.py basic --debug-sql\nWindows
...\\> runtests.py basic --debug-sql\nSecara awalan percobaan berjalan paralel dengan satu proses per inti. Ketika percobaan berjalan secara paralel, anda hanya akan melihat potongan melacak belakang untuk kegagalan percobaan apapun. Anda dapat menyesuaikan perilaku ini dengan pilihan --parallel:
Linux / macOS
$ ./runtests.py basic --parallel=1\nWindows
...\\> runtests.py basic --parallel=1\nAnda dapat menggunakan lingkungan variabel DJANGO_TEST_PROCESSES untuk tujuan ini.
To avoid polluting the global apps registry and prevent\nunnecessary table creation, models defined in a test method should be bound to\na temporary Apps instance. To do this, use the\nisolate_apps() decorator:
from django.db import models\nfrom django.test import SimpleTestCase\nfrom django.test.utils import isolate_apps\n\n\nclass TestModelDefinition(SimpleTestCase):\n @isolate_apps("app_label")\n def test_model_definition(self):\n class TestModel(models.Model):\n pass\n\n ...\n