Pytest-django: डेटा माइग्रेशन से डेटा को हटाते हुए live_server फ़िक्स्चर का उपयोग करके परीक्षण

ऐसा इसलिए है क्योंकि transactional_db स्थिरता live_server द्वारा स्वचालित रूप से उपयोग की जा रही है (इसे @pytest.mark.django_db साथ चिह्नित करने की कोई आवश्यकता नहीं है)। इस संबंध में कई मुद्दे/चर्चाएं हैं, लेकिन पिछली बार जब मैंने इसे करीब से देखा, तो इस समस्या का कोई आसान समाधान नहीं था जो डेटा माइग्रेशन का उपयोग करने के साथ आता है।
अपने डेटा माइग्रेशन/डेटा फिक्स्चर को लपेटने के लिए पाइटेस्ट फिक्स्चर का उपयोग करना एक समाधान है।
(बीटीडब्ल्यू: समय के साथ बदलने वाले बाहरी संसाधन की बजाय इस मुद्दे में परीक्षणों को बेहतर तरीके से इनलाइन करें।)

मैंने इसे अभी भी मारा और मुझे इसे ट्रैक करने में काफी समय लगा, भले ही मैं Django के परीक्षण ढांचे और माइग्रेशन से काफी परिचित हूं।

यह वास्तव में Django के TestCase एक आश्चर्यजनक प्रदर्शन ट्रेडऑफ़ है। यह यहाँ प्रलेखित है:
https://docs.djangoproject.com/hi/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 से असंबंधित - case.serialized_rollback = True अभी भी विफल रहता है क्योंकि Django एक क्रम में deserialized वस्तुओं का प्रयास करता है जो FK बाधाओं का सम्मान नहीं करता है, मुझे लगता है कि यह Django में एक बग है

बिल्कुल ठीक है :)

मेरे पास अभी ठीक करने का समय नहीं है, लेकिन django_db मार्कर में ऐसा विकल्प जोड़ना चाहिए और case.serialized_rollback = True (जैसे आपने ऊपर किया) को सेट करना अपेक्षाकृत सरल होना चाहिए।

मैंने ऊपर बताए गए Django बग के लिए टिकट: https://code.djangoproject.com/ticket/26552

@pelme - क्या यह पुल अनुरोध "अपेक्षाकृत सीधा" दृष्टिकोण लागू करता है जिसे आप कल्पना कर रहे हैं?

जनसंपर्क के लिए बहुत-बहुत धन्यवाद। कार्यान्वयन सही दिखता है और जो मैंने कल्पना की थी। मैंने एक 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 में प्राप्त नहीं कर सका। मैं अगली रिलीज के लिए इसे पाने की कोशिश करूंगा!

क्या इसे अगली रिलीज में देखने का कोई मौका है?

धन्यवाद

@ विएराट
हां शायद।

तो कृपया उससे पहले

हाय दोस्तों,
इसकी ताजा स्थिति क्या है? विशेष रूप से मैं Django से StaticLiveServerTestCase क्लास के साथ अपने टेस्ट रनर के रूप में pytest का उपयोग कर रहा हूं। मैंने वर्ग विशेषता serialized_rollback = True सेट की है लेकिन यह अनुक्रम से पहले परीक्षण को निष्पादित करते समय ही प्रभावी होता है।

बस इसी की चपेट में आ गया। चारों ओर देखने पर ऐसा लगता है कि इस मुद्दे पर कुछ जनसंपर्क हुए हैं लेकिन उनमें से कोई भी विलय नहीं हुआ प्रतीत होता है।
क्या कोई विशेष कारण है कि यह मुद्दा खुला रहता है?

कुछ पीआर

संभावना/केवल https://github.com/pytest-dev/pytest-django/issues/329 , नहीं?

पिछली बार मैंने किसी परीक्षण में मदद के बारे में पूछा था, और इसमें कई विरोध हैं (शायद केवल काले रंग के कारण)।

मैं अब भी इससे प्रभावित किसी व्यक्ति के लिए सुझाव देता हूं - मैं स्वयं इसका उपयोग नहीं कर रहा हूं।

त्वरित उत्तर @blueyed के लिए धन्यवाद।
pytest / pytest-django का मेरा ज्ञान न्यूनतम है लेकिन मैं इसे अपने किसी दिन/शायद सूची में रखूंगा! :डी

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')

मुझे मूल transactional_db स्थिरता पर निर्भर रहने के बजाय इसे पाइस्टेस्ट के रूप में कॉल करने की अनुमति नहीं देता है, जो सीधे फिक्स्चर फ़ंक्शन को कॉल करने की अनुमति नहीं देता है। मैं तब मूल स्थिरता की स्थिरता प्राप्त करता हूं और इसे अंतिम रूप देता हूं। इंडेक्स 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),
लेकिन फिर भी त्रुटि।