장고는 코드베이스의 “테스트” 디렉토리에 자체 테스트 스위트가 있습니다. 우리의 정책은 모든 시험을 항상 통과하도록 하는 것입니다.
\n테스트 제품군에 대한 모든 기여에 감사드립니다!
\nDjango 테스트는 모두 Django와 함께 제공되는 테스트 애플리케이션을 위한 테스트 인프라를 사용합니다. 새로운 테스트 작성 방법에 대한 설명은 :doc:’/topics/testing/개요’를 참조하십시오.
\n우선 장고를 깃허브 <https://github.com/django/django/fork>에서 포크하세요
\n둘째, 가상 환경을 생성하고 활성화합니다. 자세한 내용은 :doc:’기여 튜토리얼’을 참조하십시오.
\n그런 다음 포크를 복제하고 몇 가지 요구 사항을 설치한 다음 테스트를 실행하십시오.
\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 \n요구 사항을 설치하려면 컴퓨터에 설치되지 않은 일부 운영 체제 패키지가 필요할 수 있습니다. 일반적으로 오류 메시지의 마지막 줄에 대해 웹 검색을 수행하여 설치할 패키지를 확인할 수 있습니다. 필요한 경우 검색 쿼리에 운영 체제를 추가해 보십시오.
\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\n모든 테스트를 실행합니다. for details on installing the optional\ntest dependencies.
테스트를 실행하려면 사용할 데이터베이스를 정의하는 Django 설정 모듈이 필요합니다. 시작할 수 있도록 Django는 SQLite 데이터베이스를 사용하는 샘플 설정 모듈을 제공하고 사용합니다. 다른 설정 모듈을 사용하여 다른 데이터베이스로 테스트를 실행하는 방법에 대한 자세한 내용은:ref:’running-unit-tests-settings’를 참조하십시오.
\n문제가 있나요? 몇 가지 일반적인 문제는:ref:’문제 해결 장치 테스트’를 참조하십시오.
\n“Tox <https://tox.wiki/>_는 서로 다른 가상 환경에서 테스트를 실행하기 위한 도구입니다. Django에는 빌드 서버가 풀 요청에 대해 수행하는 일부 검사를 자동화하는 기본 “tox.ini”가 포함되어 있습니다. 장치 테스트 및 기타 검사(예: :ref:’import sorting’, :ref:’documentation spelling checker’ 및 :ref:’code formating’)를 실행하려면 Django 원본 트리의 임의의 위치에서 “tox” 명령을 설치하고 실행합니다.
\nLinux / macOS
$ python -m pip install tox\n$ tox\nWindows
...\\> py -m pip install tox\n...\\> tox\n기본적으로 tox``는 SQLite용 번들 테스트 설정 파일을 사용하여 테스트 스위트를 실행하고 ``black, blacken-docs, flake8, isort, lint-docs, zizmor 및 문서 맞춤법 검사기도 함께 실행합니다.. 이 문서의 다른 부분에 언급된 시스템 의존성 외에도, python3 명령은 경로에 있어야 하며 적절한 Python 버전에 연결되어 있어야 합니다. 기본 환경 목록은 다음과 같이 확인할 수 있습니다.
Linux / macOS
$ tox -l\npy3\nblack\nblacken-docs\nflake8>=3.7.0\ndocs\nisort>=7.0.0\nlint-docs\nzizmor>=1.19.0\nWindows
...\\> tox -l\npy3\nblack\nblacken-docs\nflake8>=3.7.0\ndocs\nisort>=7.0.0\nlint-docs\nzizmor>=1.19.0\n기본 환경 외에도 ``tox``는 다른 Python 버전과 다양한 데이터베이스 백엔드를 대상으로 단위 테스트를 실행할 수 있습니다. 그러나 Django의 테스트 스위트에는 SQLite를 제외한 데이터베이스 백엔드용 설정 파일이 번들되어 있지 않으므로, :ref:`create and provide your own test settings <running-unit-tests-settings>`에 따라 직접 테스트 설정을 생성하고 제공해야 합니다. 예를 들어, Python 3.12에서 PostgreSQL을 사용하여 테스트를 실행하려면 다음과 같이 합니다.
\nLinux / macOS
$ tox -e py312-postgres -- --settings=my_postgres_settings\nWindows
...\\> tox -e py312-postgres -- --settings=my_postgres_settings\n이 명령은 Python 3.12 가상 환경을 설정하고 Django의 테스트 스위트 의존성(PostgreSQL용 의존성 포함)을 설치한 뒤, 제공된 인수(이 경우 --settings=my_postgres_settings)로 ``runtests.py``를 호출합니다.
이 문서의 나머지 부분에서는 “tox” 없이 테스트를 실행하는 명령을 보여 주지만 “runtests.py”에 전달되는 모든 옵션은 위와 같이 인수 목록에 “`–“를 붙임으로써 “tox”에 전달될 수 있습니다.
\n``Tox``는 DJANGO_SETTINGS_MODULE 환경 변수가 설정되어 있는 경우 이를 따릅니다. 예를 들어, 다음은 위의 명령과 동일합니다.
$ DJANGO_SETTINGS_MODULE=my_postgres_settings tox -e py312-postgres\nWindows 사용자는 다음을 사용해야 합니다.
\n...\\> set DJANGO_SETTINGS_MODULE=my_postgres_settings\n...\\> tox -e py312-postgres\nDjango에는 특정 기여 앱의 기능을 위한 :ref:`JavaScript 세트가 포함되어 있습니다. JavaScript 테스트는 “Node.js”를 설치해야 하고 대부분의 패치에 필요하지 않기 때문에 기본적으로 ``tox``를 사용하여 실행되지 않습니다. “tox”를 사용하여 JavaScript 테스트를 실행하려면 다음과 같이 하십시오.
\nLinux / macOS
$ tox -e javascript\nWindows
...\\> tox -e javascript\n이 명령은 테스트 요구 사항이 최신인지 확인하기 위해 “npm install”을 실행한 다음 “npm test”를 실행합니다.
\n“django-docker-box”_를 사용하면 지원되는 모든 데이터베이스 및 python 버전에서 Django의 테스트 제품군을 실행할 수 있습니다. 설치 및 사용 지침은 ‘django-docker-box’_ 프로젝트 페이지를 참조하십시오.
\n포함된 설정 모듈(‘’tests/test_sqlite.py’’)을 사용하여 SQLite를 사용하여 테스트 제품군을 실행할 수 있습니다. 다른 데이터베이스를 사용하여 테스트를 실행하려면 자체 설정 파일을 정의해야 합니다. ‘’기여’’와 같은 몇 가지 시험들이 있습니다.postgres²는 특정 데이터베이스 백엔드에 한정되며 다른 백엔드로 실행할 경우 건너뜁니다. 일부 테스트는 특정 데이터베이스 백엔드에서 건너뛰거나 실패할 것으로 예상됩니다(각 백엔드의 “DatabaseFeatures.django_test_skips” 및 “DatabaseFeatures.django_testpected_fails” 참조).
\n다른 설정으로 테스트를 실행하려면 모듈이 :envvar:’PYthonPATH’에 있는지 확인하고 ‘–settings’로 모듈을 통과시킵니다.
\n: 설정은 다음과 같습니다.모든 테스트 설정 모듈의 “DATABASES” 설정은 두 개의 데이터베이스를 정의해야 합니다.
\n‘’’기본’’’입니다. 이 데이터베이스는 기본 테스트에 사용할 백엔드를 사용해야 합니다.
별칭이 ‘’기타’’인 데이터베이스입니다. “기타” 데이터베이스는 쿼리를 다른 데이터베이스로 전송할 수 있는지 테스트하는 데 사용됩니다. 이 데이터베이스는 “default”와 동일한 백엔드를 사용해야 하며 이름이 달라야 합니다.
SQLite가 아닌 백엔드를 사용하는 경우 각 데이터베이스에 대한 기타 세부 정보를 제공해야 합니다.
\n: 설정은 다음과 같습니다.’USER’ 옵션은 데이터베이스에 대한 기존 사용자 계정을 지정해야 합니다. 해당 사용자는 테스트 데이터베이스를 만들려면 “CREATE DATABASE”를 실행할 수 있는 권한이 필요합니다.
:설정:’입니다.PASSWORD’ 옵션은 :setting에 대한 암호를 제공해야 합니다.지정된 ‘USER’입니다.
테스트 데이터베이스는 “test_” 값을 :setting 값에 “test_”로 추가하여 이름을 가져옵니다.:setting에 정의된 데이터베이스에 대한 “NAME” 설정은 다음과 같습니다.’데이터베이스’입니다. 이러한 테스트 데이터베이스는 테스트가 완료되면 삭제됩니다.
\n또한 데이터베이스에서 UTF-8을 기본 문자 집합으로 사용해야 합니다. 데이터베이스 서버가 UTF-8을 기본 문자 집합으로 사용하지 않는 경우, 해당 데이터베이스의 테스트 설정 사전에 :setting:`CHARSET 값을 포함해야 합니다.
\nDjango의 전체 테스트 제품군을 실행하는 데 시간이 오래 걸리며, 예를 들어 모든 테스트를 Django에 추가했을 때 다른 모든 테스트를 실행하지 않고 빠르게 실행하고자 하는 경우 모든 테스트를 실행하는 것은 중복될 수 있습니다. 명령줄에서 테스트 모듈의 이름을 ``runtests.py``에 추가하여 단위 테스트의 하위 집합을 실행할 수 있습니다.
\n예를 들어 일반 관계 및 국제화에 대해서만 테스트를 실행하려면 다음을 입력합니다.
\nLinux / macOS
$ ./runtests.py --settings=path.to.settings generic_relations i18n\nWindows
...\\> runtests.py --settings=path.to.settings generic_relations i18n\n개별 시험의 이름은 어떻게 알 수 있나요? “tests/’를 찾습니다. 각 디렉토리 이름은 테스트 이름입니다.
\n특정 테스트 클래스만 실행하려면 개별 테스트 클래스에 대한 경로 목록을 지정할 수 있습니다. 예를 들어 ‘’i18n’’’ 모듈의 ‘’번역’을 실행하려면 타입:
\nLinux / macOS
$ ./runtests.py --settings=path.to.settings i18n.tests.TranslationTests\nWindows
...\\> runtests.py --settings=path.to.settings i18n.tests.TranslationTests\n또한 다음과 같은 개별 검사 방법을 지정할 수 있습니다.
\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\n“–start-at’ 옵션을 사용하여 지정된 최상위 모듈에서 테스트를 시작할 수 있습니다. 예를 들어 다음과 같습니다.
\nLinux / macOS
$ ./runtests.py --start-at=wsgi\nWindows
...\\> runtests.py --start-at=wsgi\n또한 ‘’–start-after’’’ 옵션을 사용하여 지정된 최상위 모듈 이후에 테스트를 실행할 수도 있습니다. 예를 들어 다음과 같습니다.
\nLinux / macOS
$ ./runtests.py --start-after=wsgi\nWindows
...\\> runtests.py --start-after=wsgi\n‘’’–reverse’’’ 옵션은 ‘’’–start-at’’’ 또는 ‘’’–start-after’’’ 옵션에는 영향을 미치지 않습니다. 또한 이러한 옵션은 테스트 레이블과 함께 사용할 수 없습니다.
\n일부 테스트에는 Selenium과 웹 브라우저가 필요합니다. 이러한 테스트를 실행하려면 selenium 패키지를 설치하고 --selenium=<BROWSERS> 옵션을 사용하여 테스트를 실행해야 합니다. 예를 들어 Firefox와 Google Chrome이 설치되어 있다면 다음과 같이 실행할 수 있습니다.
Linux / macOS
$ ./runtests.py --selenium=firefox,chrome\nWindows
...\\> runtests.py --selenium=firefox,chrome\n셀레늄을 보세요.webdriver’_package에서 사용할 수 있는 브라우저 목록입니다.
\n‘’–selenium’’을 지정하면 ‘’–selenium’’이 자동으로 셀레늄이 필요한 테스트만 실행되도록 설정됩니다.
\n일부 브라우저(예: Chrome 또는 Firefox)는 헤드리스 테스트를 지원하므로 더 빠르고 안정적입니다. 이 모드를 활성화하려면 “–headless” 옵션을 추가합니다.
\n관리자 UI 변경 사항을 테스트하려면, --screenshots 옵션을 활성화하여 selenium 테스트를 실행할 수 있습니다. 스크린샷은 tests/screenshots/ 디렉토리에 저장됩니다.
Selenium 테스트 중 스크린샷을 언제 찍을지 정의하려면, 테스트 클래스는 지원되는 스크린샷 유형("desktop_size", "mobile_size", "small_screen_size", "rtl", "dark", "high_contrast") 목록과 함께 @django.test.selenium.screenshot_cases 데코레이터를 사용해야 합니다. 이후 원하는 시점에서 ``self.take_screenshot(“unique-screenshot-name”)``을 호출하여 스크린샷을 생성할 수 있습니다. 예를 들어:
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 ...\n이는 로그인 페이지의 여러 스크린샷을 생성합니다. 데스크탑 화면, 모바일 화면, 데스크탑에서 오른쪽에서 왼쪽으로 쓰는 언어, 데스크탑의 다크 모드, 그리고 Chrome 사용 시 데스크탑의 고대비 모드에 대한 스크린샷이 생성됩니다.
\n전체 테스트 제품군을 실행하려면 다음과 같은 여러 종속성을 설치해야 합니다.
\naiosmtpd 1.4.5+
argon2-cffi 23.1.0+
asgiref 3.9.1+ (필수)
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+
:pypi:`pymemcache`와 `지원되는 Python 바인딩 <https://memcached.org/>`_
selenium 4.23.0+
sqlparse 0.5.0+ (필수)
tblib 3.0.0+
이러한 의존성은 Django 소스 트리의 tests/requirements 디렉토리에 있는 `pip requirements files <https://pip.pypa.io/en/latest/user_guide/#requirements-files>`_에서 확인할 수 있으며, 다음과 같이 설치할 수 있습니다.
Linux / macOS
$ python -m pip install -r tests/requirements/py3.txt\nWindows
...\\> py -m pip install -r tests\\requirements\\py3.txt\n설치 중 오류가 발생했다면, 시스템이 하나 이상의 Python 패키지에 대한 의존성을 해결하지 못한 것일 수 있습니다. 설치에 실패한 패키지의 문서를 참조하거나 오류 메시지를 웹에서 검색하십시오.
\n“oracle”을 사용하여 원하는 데이터베이스 어댑터를 설치할 수도 있습니다.txt,, ‘’’예’’’입니다.txt, 또는 ‘’postgres’’입니다.txt``입니다.
\nmemcached 또는 Redis 캐시 백엔드를 테스트하려면 :setting도 정의해야 합니다.memcached 또는 Redis 인스턴스를 각각 가리키는 “CACHES” 설정입니다.
\nGeoDjango 테스트를 실행하려면 :doc:’공간 데이터베이스를 설정하고 Geospacial Libraries를 설치해야 합니다.
\n이러한 각 종속성은 선택 사항입니다. 누락된 테스트가 있으면 관련 테스트를 건너뜁니다.
\n일부 자동 재로드 테스트를 실행하려면 Watchman 서비스를 설치해야 합니다.
\n기여자는 추가 테스트가 필요한 영역을 식별하기 위해 테스트 제품군에 대한 적용 범위를 실행할 것을 권장합니다. 커버리지 도구 설치 및 사용은 :ref:’테스트 코드 커버리지’에 설명되어 있습니다.
\n표준 테스트 설정을 사용하여 Django 테스트 스위트의 커버리지를 측정하려면:
\nLinux / macOS
$ coverage run ./runtests.py --settings=test_sqlite\nWindows
...\\> coverage run runtests.py --settings=test_sqlite\n커버리지를 실행한 후, 다음 명령을 실행하여 모든 커버리지 결과를 통합하려면:
\nLinux / macOS
$ coverage combine\nWindows
...\\> coverage combine\n그 다음, 다음 명령을 실행하여 HTML 형식의 보고서를 생성합니다.
\nLinux / macOS
$ coverage html\nWindows
...\\> coverage html\nDjango 테스트에 대한 적용 범위를 실행할 때 포함된 “.coverager” 설정 파일은 “coverage_html”을 보고서의 출력 디렉터리로 정의하고 결과와 관련이 없는 여러 디렉터리(테스트 코드 또는 Django에 포함된 외부 코드)도 제외합니다.
\nDjango의 지속적인 통합(CI) 시스템은 pull request에 대해 코드 커버리지 분석을 자동으로 수행하고, diff 커버리지 보고서를 포함한 코멘트를 남깁니다. 이를 통해 검토자는 변경된 코드에서 어떤 줄이 테스트로 검증되는지 확인할 수 있습니다.
\n커버리지 보고서에 표시되는 내용:
\npull request에 게시된 커버리지 보고서는 `diff-cover`_를 사용하여 PR에서 변경되었거나 추가된 줄만 분석합니다. 다음과 같은 내용을 표시합니다.
\n테스트로 커버된 줄 (✓)
테스트로 커버되지 않은 줄 (✗)
테스트로 커버될 수 없는 줄 (예: 주석, 빈 줄)
중요한 제한 사항:
\npull request의 커버리지 보고서를 검토할 때는 다음 제한 사항을 염두에 두세요.
\nDatabase-specific code: The CI coverage job runs tests using PostgreSQL\non Ubuntu. Code paths specific to other databases (SQLite, 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 (Windows, macOS) will appear as not covered when run on\nUbuntu.
커버리지가 품질을 의미하는 것은 아닙니다: “covered” 상태의 줄은 테스트 중에 실행되었음을 의미할 뿐입니다. 이는 해당 줄이 충분히 테스트되었거나 모든 엣지 케이스가 처리되었음을 보장하지 않습니다. 검토 시에는 단순한 커버리지 수치뿐만 아니라 테스트의 품질도 함께 평가하세요.
누락된 커버리지는 차단 요인이 아니라 경고로 간주하고, 문맥을 고려하여 평가해야 합니다.
\ncontrib 앱에 대한 테스트는 tests/ 디렉토리에서 찾을 수 있으며, 일반적으로 <app_name>_tests 하위에 위치합니다. 예를 들어 ``contrib.auth``에 대한 테스트는 :source:`tests/auth_tests`에 있습니다.
이전 버전에는 테스트 제품군의 실패 또는 행업 원인이 될 수 있는 버그가 종종 있으므로 a:ref:’supported Python version 의 최신 포인트 릴리스가 있는지 확인합니다.
\n**macOS**(High Sierra 이상 버전)에서는 다음 메시지가 출력된 후 테스트가 응답하지 않을 수 있습니다.
\nobjc[42074]: +[__NSPlaceholderDate initialize] may have been in progress in\nanother thread when fork() was called.\n이를 방지하려면 OBJC_DISABLE_INITIALIZE_FORK_SAFETY 환경 변수를 설정하세요. 예를 들어:
$ OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES ./runtests.py\nOr add export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES to your shell’s\nstartup file (e.g. ~/.profile).
“locales” 패키지가 설치되지 않은 경우 일부 테스트는 “UnicodeError”와 함께 실패합니다.
\n예를 들어 Debian 기반 시스템에서 다음을 실행하여 이 문제를 해결할 수 있습니다.
\n$ apt-get install locales\n$ dpkg-reconfigure locales\nmacOS 시스템의 경우 셸의 로케일을 구성하여 이 문제를 해결할 수 있습니다.
\n$ export LANG="en_US.UTF-8"\n$ export LC_ALL="en_US.UTF-8"\n“locale” 명령을 실행하여 변경 내용을 확인합니다. 선택적으로 이러한 내보내기 명령을 셸의 시작 파일(예: Bash의 경우 “~/.bashrc’’)에 추가하여 다시 입력할 필요가 없도록 합니다.
\n별도로 실행했을 때 테스트는 통과했지만 전체 제품군 내에서 실패할 경우 문제를 분석하는 데 도움이 되는 몇 가지 도구가 있습니다.
\nruntests.py``의 ``--bisect 옵션은 실패 테스트를 실행하는 동시에 각 반복에서 함께 실행되는 테스트 세트를 절반으로 줄여 실패와 관련이 있을 수 있는 적은 수의 테스트를 식별할 수 있게 합니다.
예를 들어, 자체적으로 작동하는 실패한 테스트가 ‘’ModelTest.test_eq’’라고 가정하고 다음을 사용합니다.
\nLinux / macOS
$ ./runtests.py --bisect basic.tests.ModelTest.test_eq\nWindows
...\\> runtests.py --bisect basic.tests.ModelTest.test_eq\n지정된 테스트를 방해하는 테스트를 결정합니다. 먼저 테스트 스위트의 전반부에서 테스트를 실행합니다. 오류가 발생하면 테스트 스위트의 전반부가 두 그룹으로 분할되고 각 그룹이 지정된 테스트와 함께 실행됩니다. 테스트 스위트의 전반부에 고장이 없는 경우, 테스트 스위트의 후반부는 앞에서 설명한 대로 지정된 테스트와 함께 실행되고 적절히 분할됩니다. 이 프로세스는 실패한 테스트 집합이 최소화될 때까지 반복됩니다.
\n“–pair” 옵션은 제품군의 다른 모든 테스트와 함께 주어진 테스트를 실행하므로 다른 테스트에 실패의 원인이 되는 부작용이 있는지 확인할 수 있습니다. 그래서:
\nLinux / macOS
$ ./runtests.py --pair basic.tests.ModelTest.test_eq\nWindows
...\\> runtests.py --pair basic.tests.ModelTest.test_eq\n“test_eq”는 모든 테스트 레이블과 쌍을 이룹니다.
\n“–bisect” 및 “–pair”를 모두 사용할 경우, 어떤 사례가 실패의 원인이 될 수 있는지 이미 의심하는 경우, 첫 번째 테스트 이후에 :ref:`specifying further test labels `가 교차 분석하도록 테스트를 제한할 수 있습니다.
\nLinux / macOS
$ ./runtests.py --pair basic.tests.ModelTest.test_eq queries transactions\nWindows
...\\> runtests.py --pair basic.tests.ModelTest.test_eq queries transactions\n또한 “–shuffle” 및 “–reverse” 옵션을 사용하여 임의의 테스트 세트를 랜덤 또는 역순으로 실행할 수 있습니다. 이렇게 하면 테스트를 다른 순서로 실행해도 문제가 발생하지 않는지 확인할 수 있습니다.
\nLinux / macOS
$ ./runtests.py basic --shuffle\n$ ./runtests.py basic --reverse\nWindows
...\\> runtests.py basic --shuffle\n...\\> runtests.py basic --reverse\n실패한 테스트에서 실행 중인 SQL을 검사하려면 A 옵션을 사용하여 “–debug-sql”을 설정할 수 있습니다. 이 값을 “–verbosity=2”와 결합하면 모든 SQL 쿼리가 출력됩니다.
\nLinux / macOS
$ ./runtests.py basic --debug-sql\nWindows
...\\> runtests.py basic --debug-sql\n기본적으로 테스트는 코어당 하나의 프로세스와 병렬로 실행됩니다. 그러나 테스트가 병렬로 실행되면 테스트 실패에 대한 잘린 추적만 볼 수 있습니다. “–parallel” 옵션을 사용하여 이 동작을 조정할 수 있습니다.
\nLinux / macOS
$ ./runtests.py basic --parallel=1\nWindows
...\\> runtests.py basic --parallel=1\n:envvar를 사용할 수도 있습니다.이 목적을 위한 “DJANGO_TEST_PROCESS” 환경 변수입니다.
\n전역 apps 레지스트리의 오염을 방지하고 불필요한 테이블 생성을 막기 위해, 테스트 메서드에서 정의한 모델은 임시 Apps 인스턴스에 바인딩해야 합니다. 이를 위해 isolate_apps() 데코레이터를 사용하세요:
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