---
title: "Satuan percobaan"
version: 6.0
locale: id
source: https://docs.djangoproject.com/id/6.0/internals/contributing/writing-code/unit-tests/
canonical: https://djangodocs.dev/id/6.0/internals/contributing/writing-code/unit-tests/
---
# Satuan percobaan

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!

Percobaan Django semua menggunakan infrastruktur percobaan yang dikirim dengan Django untuk aplikasi percobaan. Lihat [Menulis dan menjalankan percobaan](/id/6.0/topics/testing/overview/) untuk sebuah penjelasan bagaimana menulis percobaan baru.

## Menjalankan satuan percobaan

### Mulai cepat

Pertama, [fork Django on GitHub](https://github.com/django/django/fork).

Kedua, buat dan aktifkan lingkungan maya. Jika anda tidak akrab dengan bagaimana melakukan itu, baca [contributing tutorial](/id/6.0/intro/contributing/) kami.

Selanjutnya, kloning cabang anda, pasang beberapa persyaratan, dan jalankan percobaan:

```console
$ git clone https://github.com/YourGitHubName/django.git django-repo
$ cd django-repo/tests
$ python -m pip install -e ..
$ python -m pip install -r requirements/py3.txt
$ ./runtests.py
```

*Windows*

```doscon
...\> git clone https://github.com/YourGitHubName/django.git django-repo
...\> cd django-repo\tests
...\> py -m pip install -e ..
...\> py -m pip install -r requirements\py3.txt
...\> runtests.py
```

Installing the requirements will likely require some operating system packages
that your computer doesn't have installed. You can usually figure out which
package to install by doing a web search for the last line or so of the error
message. Try adding your operating system to the search query if needed.

If you have trouble installing an optional test dependency, you can skip that
dependency locally. For example, if installing `pylibmc` fails, comment out
its line in `requirements/py3.txt` and continue with `./runtests.py`.
Tests that require `pylibmc` will be skipped automatically. See
[Menjalankan semua percobaan](#running-unit-tests-dependencies) for details on installing the optional
test 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](#running-unit-tests-settings) untuk mempelajari bagaimana menggunakan modul pengaturan berbeda untuk menjalankan percobaan dengan basisdata berbeda.

Mempunyai masalah? Lihat [Menyelesaikan masalah](#troubleshooting-unit-tests) untuk beberapa masalah umum.

### Menjalankan percobaan menggunakan `tox`

[Tox](https://tox.wiki/) is a tool for running tests in different virtual
environments. Django includes a basic `tox.ini` that automates some checks
that our build server performs on pull requests. To run the unit tests and
other checks (such as [import sorting](/id/6.0/internals/contributing/writing-code/coding-style/#coding-style-imports), the
[documentation spelling checker](/id/6.0/internals/contributing/writing-documentation/#documentation-spelling-check), and
[code formatting](/id/6.0/internals/contributing/writing-code/coding-style/#coding-style-python)), install and run the `tox`
command from any place in the Django source tree:

```console
$ python -m pip install tox
$ tox
```

*Windows*

```doscon
...\> py -m pip install tox
...\> tox
```

By default, `tox` runs the test suite with the bundled test settings file for
SQLite, `black`, `blacken-docs`, `flake8`, `isort`, `lint-docs`,
`zizmor`, and the documentation spelling checker. In addition to the system
dependencies noted elsewhere in this documentation, the command `python3`
must be on your path and linked to the appropriate version of Python. A list of
default environments can be seen as follows:

```console
$ tox -l
py3
black
blacken-docs
flake8>=3.7.0
docs
isort>=7.0.0
lint-docs
zizmor>=1.16.3
```

*Windows*

```doscon
...\> tox -l
py3
black
blacken-docs
flake8>=3.7.0
docs
isort>=7.0.0
lint-docs
zizmor>=1.16.3
```

#### Mencoba versi Python lain dan backend basisdata

In addition to the default environments, `tox` supports running unit tests
for other versions of Python and other database backends. Since Django's test
suite doesn't bundle a settings file for database backends other than SQLite,
however, you must [create and provide your own test settings](#running-unit-tests-settings). For example, to run the tests on Python 3.12
using PostgreSQL:

```console
$ tox -e py312-postgres -- --settings=my_postgres_settings
```

*Windows*

```doscon
...\> tox -e py312-postgres -- --settings=my_postgres_settings
```

This command sets up a Python 3.12 virtual environment, installs Django's
test suite dependencies (including those for PostgreSQL), and calls
`runtests.py` with the supplied arguments (in this case,
`--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`](/id/6.0/topics/settings/#envvar-DJANGO_SETTINGS_MODULE) environment
variable, if set. For example, the following is equivalent to the command
above:

```console
$ DJANGO_SETTINGS_MODULE=my_postgres_settings tox -e py312-postgres
```

Pengguna Windows harus menggunakan:

```doscon
...\> set DJANGO_SETTINGS_MODULE=my_postgres_settings
...\> tox -e py312-postgres
```

#### Menjalankan percobaan JavaScript

Django includes a set of [JavaScript unit tests](/id/6.0/internals/contributing/writing-code/javascript/#javascript-tests) for
functions in certain contrib apps. The JavaScript tests aren't run by default
using `tox` because they require `Node.js` to be installed and aren't
necessary for the majority of patches. To run the JavaScript tests using
`tox`:

```console
$ tox -e javascript
```

*Windows*

```doscon
...\> tox -e javascript
```

Perintah ini menjalankan `npm install` untuk memastikan persyaratan percobaan terperbaharui dan kemudian menjalankan `npm test`.

### Menjalankan percobaan menggunakan `django-docker-box`

[django-docker-box](https://github.com/django/django-docker-box/) mengizinkan anda menjalankan deretan percobaan terhadap semua basisdata yang didukung dan versi python. Lihat halaman proyek [django-docker-box](https://github.com/django/django-docker-box/) untuk pemasangan dan petunjuk penggunaan.

### Gunakan modul `pengaturan` lain

The included settings module (`tests/test_sqlite.py`) allows you to run the
test suite using SQLite. If you want to run the tests using a different
database, you'll need to define your own settings file. Some tests, such as
those for `contrib.postgres`, are specific to a particular database backend
and will be skipped if run with a different backend. Some tests are skipped or
expected failures on a particular database backend (see
`DatabaseFeatures.django_test_skips` and
`DatabaseFeatures.django_test_expected_failures` on each backend).

To run the tests with different settings, ensure that the module is on your
[`PYTHONPATH`](https://docs.python.org/3/using/cmdline.html#envvar-PYTHONPATH) and pass the module with `--settings`.

Pengaturan [`DATABASES`](/id/6.0/ref/settings/#std-setting-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:

- Pilihan [`USER`](/id/6.0/ref/settings/#std-setting-USER) butuh menentukan akun pengguna yang ada ntuk basisdata. Bahwa pengguna butuh perizinan untuk menjalankan `CREATE DATABASE` sehingga basisdata percobaan dapat dibuat.
- Pilihan [`PASSWORD`](/id/6.0/ref/settings/#std-setting-PASSWORD) butuh disediakan sandi untuk the [`USER`](/id/6.0/ref/settings/#std-setting-USER) yang telah ditentukan.

Basisdata percobaan mendapatkan nama-nama mereka dengan mengawali `test_` pada nilai dari pengaturan [`NAME`](/id/6.0/ref/settings/#std-setting-NAME) untuk basisdata ditentukan di [`DATABASES`](/id/6.0/ref/settings/#std-setting-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`](/id/6.0/ref/settings/#std-setting-TEST_CHARSET) di kamus pengaturan untuk basisdata yang berlaku.

### Menjalankan hanya beberapa untuk percobaan

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:

```console
$ ./runtests.py --settings=path.to.settings generic_relations i18n
```

*Windows*

```doscon
...\> runtests.py --settings=path.to.settings generic_relations i18n
```

Bagaimana 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:

```console
$ ./runtests.py --settings=path.to.settings i18n.tests.TranslationTests
```

*Windows*

```doscon
...\> runtests.py --settings=path.to.settings i18n.tests.TranslationTests
```

Melampaui itu, anda dapat menentukan metode percobaan sendiri seperti ini:

```console
$ ./runtests.py --settings=path.to.settings i18n.tests.TranslationTests.test_lazy_objects
```

*Windows*

```doscon
...\> runtests.py --settings=path.to.settings i18n.tests.TranslationTests.test_lazy_objects
```

Anda dapat menjalankan percobaan dimulai pada menentukan modul tingkat-atas dengan pilihan `--start-at`. Sebagai contoh:

```console
$ ./runtests.py --start-at=wsgi
```

*Windows*

```doscon
...\> runtests.py --start-at=wsgi
```

Anda dapat juga menjalankan percobaan dimulai setelah modul tingkat-atas ditentukan dengan pilihan `--start-after`. Sebagai contoh:

```console
$ ./runtests.py --start-after=wsgi
```

*Windows*

```doscon
...\> runtests.py --start-after=wsgi
```

Catat bahwa pilihan `--reverse` tidak berpengaruh pada pilihan `--start-at` atau `--start-after`. Bahkan pilihan ini tidak dapat digunakan dengan label percobaan.

### Menjalankan percobaan Selenium

Some tests require Selenium and a web browser. To run these tests, you must
install the [selenium](https://pypi.org/project/selenium/) package and run the tests with the
`--selenium=<BROWSERS>` option. For example, if you have Firefox and Google
Chrome installed:

```console
$ ./runtests.py --selenium=firefox,chrome
```

*Windows*

```doscon
...\> runtests.py --selenium=firefox,chrome
```

Lihat paket [selenium.webdriver](https://github.com/SeleniumHQ/selenium/tree/trunk/py/selenium/webdriver) untuk daftar perambah tersedia.

Menentukan `--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.

#### Screenshot tests

For testing changes to the admin UI, the selenium tests can be run with the
`--screenshots` option enabled. Screenshots will be saved to the
`tests/screenshots/` directory.

To define when screenshots should be taken during a selenium test, the test
class must use the `@django.test.selenium.screenshot_cases` decorator with a
list of supported screenshot types (`"desktop_size"`, `"mobile_size"`,
`"small_screen_size"`, `"rtl"`, `"dark"`, and `"high_contrast"`). It
can then call `self.take_screenshot("unique-screenshot-name")` at the desired
point to generate the screenshots. For example:

```
from django.test.selenium import SeleniumTestCase, screenshot_cases
from django.urls import reverse

class SeleniumTests(SeleniumTestCase):
    @screenshot_cases(["desktop_size", "mobile_size", "rtl", "dark", "high_contrast"])
    def test_login_button_centered(self):
        self.selenium.get(self.live_server_url + reverse("admin:login"))
        self.take_screenshot("login")
        ...
```

This generates multiple screenshots of the login page - one for a desktop
screen, one for a mobile screen, one for right-to-left languages on desktop,
one for the dark mode on desktop, and one for high contrast mode on desktop
when using chrome.

### Menjalankan semua percobaan

Jika anda ingin menjalankan deretan lengkap dari percobaan, anda akan butuh memasang sejumlah ketergantungan:

- [aiosmtpd](https://pypi.org/project/aiosmtpd/) 1.4.5+
- [argon2-cffi](https://pypi.org/project/argon2-cffi/) 23.1.0+
- [asgiref](https://pypi.org/project/asgiref/) 3.9.1+ (required)
- [bcrypt](https://pypi.org/project/bcrypt/) 4.1.1+
- [colorama](https://pypi.org/project/colorama/) 0.4.6+
- [docutils](https://pypi.org/project/docutils/) 0.22+
- [geoip2](https://pypi.org/project/geoip2/) 4.8.0+
- [Jinja2](https://pypi.org/project/Jinja2/) 2.11+
- [numpy](https://pypi.org/project/numpy/) 1.26.0+
- [Pillow](https://pypi.org/project/Pillow/) 10.1.0+
- [PyYAML](https://pypi.org/project/PyYAML/) 6.0.2+
- [pywatchman](https://pypi.org/project/pywatchman/)
- [redis](https://pypi.org/project/redis/) 5.1.0+
- [pymemcache](https://pypi.org/project/pymemcache/), plus a [supported Python binding](https://memcached.org/)
- [gettext](https://www.gnu.org/software/gettext/manual/gettext.html)
  ([gettext pada Windows](/id/6.0/topics/i18n/translation/#gettext-on-windows))
- [selenium](https://pypi.org/project/selenium/) 4.23.0+
- [sqlparse](https://pypi.org/project/sqlparse/) 0.5.0+ (required)
- [tblib](https://pypi.org/project/tblib/) 3.0.0+

You can find these dependencies in [pip requirements files](https://pip.pypa.io/en/latest/user_guide/#requirements-files) inside the
`tests/requirements` directory of the Django source tree and install them
like so:

```console
$ python -m pip install -r tests/requirements/py3.txt
```

*Windows*

```doscon
...\> py -m pip install -r tests\requirements\py3.txt
```

Jika 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.

Anda 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
define a [`CACHES`](/id/6.0/ref/settings/#std-setting-CACHES) setting that points at your memcached or Redis
instance respectively.

To run the GeoDjango tests, you will need to [set up a spatial database
and install the Geospatial libraries](/id/6.0/ref/contrib/gis/install/).

Masing-masing ketergantungan ini adalah pilihan. Jika anda kehilangan salah satu dari mereka, percobaan terkait akan dilewati.

To run some of the autoreload tests, you'll need to install the
[Watchman](https://facebook.github.io/watchman/) service.

### Cakupan kode

Pembantu mendorong menjalankan cakupan pada deretan percobaan untuk mencirikan kawasan yang butuh percobaan tambahan. Pemasangan alat cakupan dan penggunaan digambarkan dalam [testing code coverage](/id/6.0/topics/testing/advanced/#topics-testing-code-coverage).

To run coverage on the Django test suite using the standard test settings:

```console
$ coverage run ./runtests.py --settings=test_sqlite
```

*Windows*

```doscon
...\> coverage run runtests.py --settings=test_sqlite
```

After running coverage, combine all coverage statistics by running:

```console
$ coverage combine
```

*Windows*

```doscon
...\> coverage combine
```

Setelah itu bangkitkan laporan html dengan menjalankan:

```console
$ coverage html
```

*Windows*

```doscon
...\> coverage html
```

Ketika 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).

### Code coverage on pull requests

Django's continuous integration (CI) system automatically runs code coverage
analysis on pull requests and posts a comment with a diff coverage report. This
helps reviewers see which lines in the changed code are covered by tests.

**What the coverage report shows:**

The coverage report posted on pull requests uses [diff-cover](https://github.com/Bachmann1234/diff_cover) to analyze only
the lines that were changed or added in the PR. It shows:

- Lines that are covered by tests (✓)
- Lines that are not covered by tests (✗)
- Lines that cannot be covered (e.g., comments, blank lines)

**Important limitations:**

When reviewing coverage reports on pull requests, keep these limitations in
mind:

- **Database-specific code:** The CI coverage job runs tests using SQLite on
  Windows. Code paths specific to other databases (PostgreSQL, MySQL, Oracle)
  will appear as "not covered" even if database-specific tests exist. This is
  expected and acceptable.
- **Platform-specific code:** Similarly, code that only runs on certain
  operating systems (Linux, macOS) will appear as not covered when run on
  Windows.
- **Coverage doesn't equal quality:** A line being "covered" only means it was
  executed during tests. It doesn't guarantee the line is well-tested or that
  all edge cases are handled. During review, assess test quality beyond just
  coverage numbers.

Missing coverage should be considered a warning rather than a blocker and
should be evaluated in context.

## Aplikasi bantuan

Tests for contrib apps can be found in the [tests/](https://github.com/django/django/blob/stable/6.0.x/tests/) directory,
typically under `<app_name>_tests`. For example, tests for `contrib.auth`
are located in [tests/auth\_tests](https://github.com/django/django/blob/stable/6.0.x/tests/auth_tests).

## Menyelesaikan masalah

### Rangkaian uji coba menggantung atau menunjukkan kegagalan pada cabang `main`

Pastikan anda memiliki titik terbitan terakhir dari [supported Python version](/id/6.0/faq/install/#faq-python-version-support), sejak sering ada kesalahan dalam versi sebelumnya yang mungkin menyebabkan deretan percobaan gagal atau menggantung.

On **macOS** (High Sierra and newer versions), you might see this message
logged, after which the tests hang:

```pytb
objc[42074]: +[__NSPlaceholderDate initialize] may have been in progress in
another thread when fork() was called.
```

Untuk menghindari ini setel variabel lingkungan  `OBJC_DISABLE_INITIALIZE_FORK_SAFETY`, sebagai contoh:

```shell
$ OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES ./runtests.py
```

Atau tambah `export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES` ke berkas awal shell anda (contoh `~/.profile`).

### Banyak percobaan gagal dengan `UnicodeEncodeError`

Jika paket `locales` tidak terpasang, beberapa percobaan akan gagal dengan `UnicodeEncodeError`.

Anda dapat menyelesaikan ini pada sistem berdasarkan-Debian, sebagai contoh, dengan menjalankan:

```console
$ apt-get install locales
$ dpkg-reconfigure locales
```

Anda dapat mengatasi ini untuk sistem macOS dengan mengkonfigurasi lokal shell anda:

```console
$ export LANG="en_US.UTF-8"
$ export LC_ALL="en_US.UTF-8"
```

Jalankan 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.

### Percobaan hanya gagal di kombinasi

Dalam hal sebuah percobaan lulus ketika berjalan di pemisahan tetapi gagal dalam deretan keseluruhan, kami mempunyai beberapa alat untuk membantu menganalisa masalah.

Pilihan `--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:

```console
$ ./runtests.py --bisect basic.tests.ModelTest.test_eq
```

*Windows*

```doscon
...\> runtests.py --bisect basic.tests.ModelTest.test_eq
```

akan 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.

Pilihan `--pair` menjalankan percobaan diberikan bersama setiap percobaan lain dari deretan, membiarkan anda memeriksa jika percobaan lain mempunyai pengaruh-samping yang menyebabkan kegagalan. Jadi:

```console
$ ./runtests.py --pair basic.tests.ModelTest.test_eq
```

*Windows*

```doscon
...\> runtests.py --pair basic.tests.ModelTest.test_eq
```

akan 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](#runtests-specifying-labels) setelah yang pertama:

```console
$ ./runtests.py --pair basic.tests.ModelTest.test_eq queries transactions
```

*Windows*

```doscon
...\> runtests.py --pair basic.tests.ModelTest.test_eq queries transactions
```

You can also try running any set of tests in a random or reverse order using
the `--shuffle` and `--reverse` options. This can help verify that
executing tests in a different order does not cause any trouble:

```console
$ ./runtests.py basic --shuffle
$ ./runtests.py basic --reverse
```

*Windows*

```doscon
...\> runtests.py basic --shuffle
...\> runtests.py basic --reverse
```

### Melihat permintaan SQL berjalan selama percobaan

Jika anda berharap menguji SQL yang sedang berjalan dalam kegagalan percobaan, anda dapat menyalakan [SQL logging](/id/6.0/ref/logging/#django-db-logger) menggunakan pilihan `--debug-sql`. Jika anda menggabungkan ini dengan `--verbosity=2`, semua permintaan SQL akan mengeluarkan:

```console
$ ./runtests.py basic --debug-sql
```

*Windows*

```doscon
...\> runtests.py basic --debug-sql
```

### Melihat melacak kembali penuh dari kegagalan percobaan

Secara 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`:

```console
$ ./runtests.py basic --parallel=1
```

*Windows*

```doscon
...\> runtests.py basic --parallel=1
```

Anda dapat menggunakan lingkungan variabel [`DJANGO_TEST_PROCESSES`](/id/6.0/ref/django-admin/#envvar-DJANGO_TEST_PROCESSES) untuk tujuan ini.

## Tip untuk menulis percobaan

### Mengasingkan pendaftaran model

To avoid polluting the global [`apps`](/id/6.0/ref/applications/#django.apps.apps) registry and prevent
unnecessary table creation, models defined in a test method should be bound to
a temporary `Apps` instance. To do this, use the
[`isolate_apps()`](/id/6.0/topics/testing/tools/#django.test.utils.isolate_apps) decorator:

```
from django.db import models
from django.test import SimpleTestCase
from django.test.utils import isolate_apps

class TestModelDefinition(SimpleTestCase):
    @isolate_apps("app_label")
    def test_model_definition(self):
        class TestModel(models.Model):
            pass

        ...
```

> **Mengatur app_label**
>
> Model ditentukan dalam cara percobaan dengan tidak eksplisit [`app_label`](/id/6.0/ref/models/options/#django.db.models.Options.app_label) secara otomatis diberikan label dari aplikasi dimana kelas percobaan mereka ditempatkan.
>
> Untuk memastikan model ditentukan dalam konteks instance [`isolate_apps()`](/id/6.0/topics/testing/tools/#django.test.utils.isolate_apps) dengan benar dipasang, anda harus lolos kumpulan `app_label` ditargetkan sebagai argumen:
>
> *`tests/app_label/tests.py`*
>
> ```python
> from django.db import models
> from django.test import SimpleTestCase
> from django.test.utils import isolate_apps
>
>
> class TestModelDefinition(SimpleTestCase):
>     @isolate_apps("app_label", "other_app_label")
>     def test_model_definition(self):
>         # This model automatically receives app_label='app_label'
>         class TestModel(models.Model):
>             pass
>
>         class OtherAppModel(models.Model):
>             class Meta:
>                 app_label = "other_app_label"
>
>         ...
> ```