Pytest-django: 데이터 마이그레이션에서 데이터를 제거하는 live_server 고정 장치를 사용한 테스트

transactional_db 고정 장치가 live_server 의해 자동으로 사용되기 때문입니다( @pytest.mark.django_db 로 표시할 필요가 없음). 이와 관련하여 여러 가지 문제/토론이 있지만 지난번에 자세히 살펴보았을 때 데이터 마이그레이션을 사용하여 발생하는 이 문제에 대한 쉬운 해결책은 없었습니다.
해결 방법은 pytest 고정 장치를 사용하여 데이터 마이그레이션/데이터 고정 장치를 래핑하는 것입니다.
(btw: 시간이 지남에 따라 변경될 수 있는 외부 리소스보다 문제에 테스트를 인라인으로 넣는 것이 좋습니다.)

나도 방금 이것을 쳤고 Django의 테스트 프레임워크 및 마이그레이션에 상당히 익숙하지만 추적하는 데 오랜 시간이 걸렸습니다.

이것은 실제로 Django의 TestCase 의 놀라운 성능 절충안입니다. 여기에 문서화되어 있습니다.
https://docs.djangoproject.com/en/1.9/topics/testing/overview/#rollback -emulation

일반 Django 테스트 스위트에서 해결 방법은 테스트 케이스에 serialized_rollback = True 클래스 속성을 설정하는 것입니다.

pytest-django의 동적으로 생성된 테스트 클래스로 동일한 효과를 얻는 방법을 모르겠습니다.

다음 변경은 가장 효율이 낮은 동작을 무조건 선택하는 대신 문제를 "해결"합니다.

--- pytest_django/fixtures.py.orig  2016-04-27 17:12:25.000000000 +0200
+++ pytest_django/fixtures.py   2016-04-27 17:21:50.000000000 +0200
@@ -103,6 +103,7 @@

     if django_case:
         case = django_case(methodName='__init__')
+        case.serialized_rollback = True
         case._pre_setup()
         request.addfinalizer(case._post_teardown)

다음 기술은 효과가 있지만 다소 명백한 이유로 추천할 수 없습니다...

import pytest
from django.core.management import call_command
from pytest_django.fixtures import transactional_db as _transactional_db


def _reload_fixture_data():
    fixture_names = [
        # Create fixtures for the data created by data migrations
        # and list them here.
    ]
    call_command('loaddata', *fixture_names)


@pytest.fixture(scope='function')
def transactional_db(request, _django_db_setup, _django_cursor_wrapper):
    """
    Override a pytest-django fixture to restore the contents of the database.

    This works around https://github.com/pytest-dev/pytest-django/issues/329 by
    restoring data created by data migrations. We know what data matters and we
    maintain it in (Django) fixtures. We don't read it from the database. This
    causes some repetition but keeps this (pytest) fixture (almost) simple.

    """
    try:
        return _transactional_db(request, _django_db_setup, _django_cursor_wrapper)
    finally:
        # /!\ Epically shameful hack /!\ _transactional_db adds two finalizers:
        # _django_cursor_wrapper.disable() and case._post_teardown(). Note that
        # finalizers run in the opposite order of that in which they are added.
        # We want to run after case._post_teardown() which flushes the database
        # but before _django_cursor_wrapper.disable() which prevents further
        # database queries. Hence, open heart surgery in pytest internals...
        finalizers = request._fixturedef._finalizer
        assert len(finalizers) == 2
        assert finalizers[0].__qualname__ == 'CursorManager.disable'
        assert finalizers[1].__qualname__ == 'TransactionTestCase._post_teardown'
        finalizers.insert(1, _reload_fixture_data)

serialized_rollback 를 조건부로 활성화하는 옵션이 좋은 해결책이 될까요?

즉, 뭔가

@pytest.mark.django_db(transaction=True, serialized_rollback=True)
def test_foo():
    ...

나는 그것이 좋을 것이라고 생각한다.

내 사용 사례:

• transactional_db 고정 장치는 live_server 에 의해 트리거되지만 직렬화된 롤백을 지정하기 위해 django_db 고정 장치를 추가하는 데 신경쓰지 않습니다.
• pytest-django와 관련 없음 -- Django가 FK 제약 조건을 존중하지 않는 순서로 역직렬화된 객체를 시도하기 때문에 case.serialized_rollback = True 여전히 실패합니다. Django의 버그라고 생각합니다.

좋아, 완벽해 :)

지금은 수정할 시간이 없지만 django_db 마커에 이러한 옵션을 추가하고 case.serialized_rollback = True (위에서 한 것처럼)은 비교적 간단해야 합니다.

위에서 언급한 Django 버그 티켓: https://code.djangoproject.com/ticket/26552

@pelme -- 이 풀 리퀘스트가 당신이 구상하고 있는 "상대적으로 간단한" 접근 방식을 구현합니까?

PR 정말 감사합니다. 구현이 정확하고 내가 상상한 것처럼 보입니다. 나는 serialized_rollback 고정 장치가 있다고 생각하지 않았지만 다른 고정 장치에서 이 동작을 강제할 수 있는 것이 실제로 유용합니다.

이것에 대한 테스트도 필요하지만 구현은 정확해 보입니다!

패치를 다듬을 시간을 찾으려고 노력할 것입니다(아직 실행하지도 않았습니다). 이것을 사용하기 전에 Django의 수정된 버그도 수정해야 합니다.

pytest-django ≥ 3.0에 대한 위의 해킹 버전 업데이트:

@pytest.fixture(scope='function')
def transactional_db(request, django_db_setup, django_db_blocker):
    """
    Override a pytest-django fixture to restore the contents of the database.

    This works around https://github.com/pytest-dev/pytest-django/issues/329 by
    restoring data created by data migrations. We know what data matters and we
    maintain it in (Django) fixtures. We don't read it from the database. This
    causes some repetition but keeps this (pytest) fixture (almost) simple.

    """
    try:
        return _transactional_db(request, django_db_setup, django_db_blocker)
    finally:
        # /!\ Epically shameful hack /!\ _transactional_db adds two finalizers:
        # django_db_blocker.restore() and test_case._post_teardown(). Note that
        # finalizers run in the opposite order of that in which they are added.
        # We want to run after test_case._post_teardown() flushes the database
        # but before django_db_blocker.restore() prevents further database
        # queries. Hence, open heart surgery in pytest internals...
        finalizers = request._fixturedef._finalizer
        assert len(finalizers) == 2
        assert finalizers[0].__qualname__ == '_DatabaseBlocker.restore'
        assert finalizers[1].__qualname__ == 'TransactionTestCase._post_teardown'
        finalizers.insert(1, _reload_fixture_data)

업데이트에 감사드리며 3.0에 적용하지 못해 죄송합니다. 나는 다음 릴리스를 위해 이것을 얻으려고 노력할 것입니다!

다음 릴리스에서 볼 기회가 있습니까?

감사 해요

@Wierrat
네 아마도.

그 전에 https://github.com/pytest-dev/pytest-django/pull/353에 대한 테스트를 도와주시겠습니까?

안녕 여러분,
이것의 최신 상태는 무엇입니까? 특히 Django의 StaticLiveServerTestCase 클래스와 함께 테스트 러너로 pytest를 사용하고 있습니다. 클래스 속성 serialized_rollback = True 했지만 시퀀스에서 첫 번째 테스트를 실행할 때만 효과가 있는 것 같습니다.

이놈에게 막 걸렸습니다. 주위를 둘러보면 이 문제에 대한 PR이 있었던 것 같지만 그 중 어느 것도 병합되지 않은 것으로 보입니다.
이 문제가 계속 열려 있는 특별한 이유가 있습니까?

일부 홍보

https://github.com/pytest-dev/pytest-django/issues/329 , 아니요?

마지막으로 테스트에 대한 도움을 요청했는데 몇 가지 충돌이 있습니다(검정색 때문일 수도 있음).

나는 여전히 영향을 받는 누군가에게 도움을 줄 것을 제안합니다. 나는 그것을 직접 사용하지 않습니다.

@blueyed 빠른 답변 감사합니다.
pytest / pytest-django에 대한 나의 지식은 미미하지만 그것을 내 언젠가/아마도 목록에 넣을 것입니다! :NS

pytest 5.2.1, pytest-django 3.5.1에 ​​대한 위의 해킹 버전 업데이트:

from functools import partial

@pytest.fixture
def transactional_db(request, transactional_db, django_db_blocker):
    # Restore DB content after all of transactional_db's finalizers have
    # run. Finalizers are run in the opposite order of that in which they
    # are added, so we prepend the restore to the front of the list.
    #
    # Works for pytest 5.2.1, pytest-django 3.5.1
    restore = partial(_restore_db_content, django_db_blocker)
    finalizers = request._fixture_defs['transactional_db']._finalizers
    finalizers.insert(0, restore)

    # Simply restoring after yielding transactional_db wouldn't work because
    # it would run before transactional_db's finalizers which contains the truncate.
    return transactional_db

def _restore_db_content(django_db_fixture, django_db_blocker):
    with django_db_blocker.unblock():
        call_command('loaddata', '--verbosity', '0', 'TODO your fixture')

pytest가 더 이상 고정 함수를 직접 호출하는 것을 허용하지 않으므로 호출하는 대신 원래 transactional_db 고정 장치에 의존해야 했습니다. 그런 다음 원래 조명기의 조명기 def를 가져와서 종료자를 앞에 추가합니다. 인덱스 1에 삽입하는 것이 여전히 작동하는 동안 모든 종료자 앞에 삽입하고 복원 기능에서 django_db_blocker 를 사용합니다.

편집: 마지막으로 불필요한 시도를 제거했습니다.

@lukaszb

https://github.com/pytest-dev/pytest-django/issues/848

이 버전의 pytest-django(https://github.com/pytest-dev/pytest-django/pull/721/files)를 사용합니다.
그러나 여전히 오류.