@ludbek हमने ऐसी सुविधा को भी याद किया है और इस सुविधा के लिए प्लगइन बनाया है:
https://github.com/tipsi/pytest-tipsi-django (उपयोग: https://github.com/tipsi/pytest-tipsi-django/blob/master/test_django_plugin/app/tests/test_transactions.py)
के साथ संयोजन के रूप में:
https://github.com/tipsi/pytest-tipsi-testing
यह आपको लेनदेन को नेस्ट करने और निष्पादन/शटडाउन ऑर्डर को सही करने की क्षमता देता है।

@cybergrind उत्तर देने के लिए धन्यवाद। मैं निश्चित रूप से इसकी जांच करूंगा और आपको बता दूंगा कि यह कैसा रहा।

Django के यूनिटटेस्ट क्लास-आधारित परीक्षणों से पाइटेस्ट-डीजेंगो तक आने के लिए यह मेरे लिए सबसे बड़ा दर्द बिंदु रहा है - Django में हम एक बार महंगा डीबी संचालन चलाने के लिए setUpTestData का उपयोग करते हैं (सत्र-स्कोप्ड पाइटेस्ट फिक्स्चर के बराबर), और फिर वर्ग संदर्भों को ताज़ा करने के लिए setUp में obj.refresh_from_db() चलाने के लिए एक चालाक चाल है।

यहां तक ​​​​कि अगर मैं सिर्फ एक डीबी मॉडल उदाहरण बना रहा हूं, और इसे हर टीसी को फिर से लोड कर रहा हूं, तो यह प्रत्येक टेस्ट केस में बनाने से लगभग हमेशा तेज होता है।

यह बहुत अच्छा होगा यदि हम pytest-tipsi-django मर्ज किए गए अपस्ट्रीम से सत्र-स्कोप्ड फिक्स्चर प्राप्त कर सकें, यदि यह एक संभावना है; इस मुद्दे और समाधान को खोजने में थोड़ी खुदाई हुई।

अरे @paultilady

मुझे यकीन नहीं है कि pytest-tipsi-djanjo से दृष्टिकोण $#$1 pytest #$ के लिए सामान्य परीक्षण मॉडल में फिट बैठता है। सबसे अधिक ध्यान देने योग्य अंतर जुड़नार पर परिष्करण है: वर्तमान में pytest व्यापक दायरे के साथ अनावश्यक जुड़नार को स्पष्ट रूप से समाप्त नहीं करता है। इसलिए आपको विशेष क्रम में लेनदेन को स्पष्ट रूप से समाप्त करने की आवश्यकता है और सामान्य तौर पर, यह बहुत अलग प्रभाव पैदा कर सकता है (वर्तमान में pytest सक्रिय परीक्षण और इसके जुड़नार की बिल्कुल भी आवश्यकता नहीं होने पर भी जुड़नार सक्रिय रख सकते हैं)।

हमें अपनी परियोजना में परीक्षणों को इस दृष्टिकोण में बदलना पड़ा क्योंकि हमें कभी-कभी कुछ बड़े परिदृश्यों का परीक्षण करने की आवश्यकता होती है और हमने मौजूदा मैन्युअल लेनदेन प्रबंधन को बड़े परीक्षणों में थोड़ा बेहतर फिक्स्चर के साथ बदल दिया है, लेकिन इसे अभी भी ऑर्डर परीक्षणों पर ध्यान देने की आवश्यकता है।

अभी मैं इसके लिए केवल एक ही समाधान देख सकता हूं: दस्तावेज़ीकरण में किसी प्रकार का अक्सर पूछे जाने वाले प्रश्न डालना।

अतिरिक्त विवरण @cybergrind के लिए धन्यवाद। मैंने इसमें थोड़ा और खोदा है, लेकिन आज के लिए समय समाप्त हो गया है - यहाँ वह जगह है जहाँ मुझे मिला है, मैं इस बात की जाँच की सराहना करता हूँ कि यह दृष्टिकोण उपयोगी है या नहीं, क्योंकि मैं हूँ पाइटेस्ट इंटर्नल से वह परिचित नहीं है।

इसके अलावा, मुझे समझ में नहीं आता कि "पाइटेस्ट व्यापक दायरे के साथ अनावश्यक फिक्स्चर को स्पष्ट रूप से समाप्त नहीं करता है", क्या आप उस पर थोड़ा और विस्तार कर सकते हैं? क्या यह अंतिम रूप देने वालों की बात कर रहा है? जो मैंने नीचे लिखा है, वह प्रभावित हो सकता है।

pytest-django प्लगइन django_db चिह्न का उपयोग करता है, जिसे प्लगइन.py (https://github.com/pytest-dev/pytest-django/blob/master/pytest_django/plugin.py) में _django_db_marker में हैंडल किया जाता है। #L375), फंक्शन-स्कोप्ड db फिक्स्चर (https://github.com/pytest-dev/pytest-django/blob/master/pytest_django/fixtures.py#L142) में कॉल कर रहे हैं। यह फिक्स्चर एक Django TestCase को इंस्टेंट करता है, और इसके _pre_setup फ़ंक्शन को कॉल करता है (और _post_teardown को एनक्यू करता है)।

मैं कुछ विकल्प देख सकता हूं:

मैं सोच रहा हूं कि क्या हम वैकल्पिक रूप से कक्षा- या सत्र- करने के लिए _django_db_marker बढ़ा सकते हैं-
स्कोप्ड सेटअप भी है, जो अनिवार्य रूप से db जैसा ही काम करेगा, लेकिन cls.setUpTestData के बराबर कॉल करना या इसके बजाय मार्क kwargs में पास किए गए फ़ंक्शन को कॉल करना।

क्लास-स्कोप के लिए, और मैं सत्र-स्कोप के लिए भी मान रहा हूं, अपेक्षित व्यवहार बाद में डीबी को वापस रोल करना होगा, इसलिए हमें मूल रूप से स्कोप्ड फिक्स्चर की आवश्यकता होती है जो सही क्रम में ट्रिगर होती है, और प्रत्येक अपना परमाणु सेट करता है लेन - देन। मेरा मानना ​​​​है कि इसका मतलब है कि इसके बगल में चलने वाली एक अलग स्थिरता के बजाय इसे db स्थिरता में संशोधन करने की आवश्यकता है।

इस तरह हम निर्दिष्ट किसी भी वर्ग-/सत्र-स्तरीय सेटअप को सही ढंग से ट्रिगर करेंगे, और उस सेटअप को प्रति वर्ग/सत्र में एक बार कॉल किया जाएगा। मेरा मानना ​​​​है कि चिह्न में संशोधन की आवश्यकता है क्योंकि यदि आप केवल एक सत्र-स्कोप्ड फ़ंक्शन सेट करते हैं जो मैन्युअल रूप से django_db_blocker.unblock() ट्रिगर करता है, ऐसा लगता है कि django_db चिह्न ने पहला लेनदेन स्थापित किया है।

यह कुछ इस तरह दिख सकता है ( plugin.py _django_db_marker() में):

    if marker:
        if marker.session_db:
            getfixturevalue(request, 'db_session')

        if marker.class_db:
            getfixturevalue(request, 'db_class')

        validate_django_db(marker)
        if marker.transaction:
            getfixturevalue(request, 'transactional_db')
        else:
            getfixturevalue(request, 'db')

क्या यह पागल बात है, या यह धागा आगे की खोज के लायक है?

अंतिम रूप देने के संबंध में: https://github.com/tipsi/pytest-tipsi-testing/blob/master/tests/test_finalization.py

यह परीक्षण गैर-फ़ंक्शन स्तर डेटाबेस फिक्स्चर के समान स्पष्ट रूप से अंतिम रूप दिए बिना काम नहीं करता है। और यह pytest कार्यान्वयन के बारे में है, इसलिए इसे ठीक करने के लिए pytest-django में करने के लिए कुछ भी नहीं है।

#388 और #33 . का डुप्लीकेट

धन्यवाद, समापन।

33 बंद है, और #388 में कोई सार्थक चर्चा नहीं है (इसके विपरीत)। इसे बंद करने के लिए अजीब लगता है @blueyed , अगर कुछ भी मैं # 388 को बंद करने का सुझाव दूंगा और इस समस्या के लिए इसे विहित टिकट बनाऊंगा।

धन्यवाद!

मैं भी इस कार्यक्षमता की बहुत सराहना करता हूं।

@मकोकोटोविच
कितना? इसे स्वयं करने के लिए पर्याप्त है? ;)

वैसे भी, यहां मुख्य/मौलिक समस्या (मूल टिप्पणी से) पहले से ही है कि परीक्षणों के दौरान डीबी रीसेट हो गया है, इसलिए सत्र स्कोप्ड स्थिरता रखने का कोई छोटा तरीका नहीं है।

हालांकि क्या काम कर सकता है साथ में कुछ है:

@pytest.fixture(scope="session")
def django_db_setup(django_db_setup, django_db_blocker):
    with django_db_blocker.unblock():
        with transaction.atomic():  # XXX: could/should use `TestCase_enter_atomics` for multiple dbs
            load_time_consuming_db_fixture()
            yield

सब कुछ एक अतिरिक्त परमाणु ब्लॉक में लपेटने का विचार। हालांकि इसका परीक्षण नहीं किया गया है, और इसके लिए आपको वास्तव में TransactionTestCase का उपयोग करने की आवश्यकता हो सकती है।

@पॉल्टीप्लाडी
आपकी टिप्पणी अच्छी लगती है - यानी यह आगे की खोज के लायक है AFAICS (मेरी पिछली टिप्पणी भी देखें)।

@blueyed हम एक वर्ष से अधिक समय से इस तरह के दृष्टिकोण का उपयोग कर रहे हैं (सब कुछ एक अतिरिक्त परमाणु ब्लॉक में लपेटें) यह बहुत अच्छी तरह से काम करता है।
लेकिन आप ऐसा कुछ ड्रॉप-इन नहीं कर सकते क्योंकि पाइस्टेस्ट में नियतात्मक नहीं है जहां सत्र-स्तर (और परीक्षण के अलावा अन्य) बंद हो जाएगा, इसलिए इसे डीबी लेनदेन की निर्भरताओं पर नज़र रखने की आवश्यकता होगी, भले ही उन्हें एक दूसरे की आवश्यकता हो या सीधे नहीं .
तो आपको अगले परीक्षण से पहले स्पष्ट रूप से लेनदेन स्टैक और क्लोज नेस्टेड लेनदेन को ट्रैक करने की आवश्यकता है। इस तरह से किया जा सकता है: https://github.com/tipsi/pytest-tipsi-django/blob/master/pytest_tipsi_django/django_fixtures.py#L46

क्षमा करें, मैं स्पष्ट करना चाहता हूं क्योंकि मेरा मानना ​​​​है कि मैं उसी मुद्दे पर चल रहा हूं:

अगर मैं एक फिक्स्चर बनाना चाहता हूं जो एक नई डीबी ऑब्जेक्ट बनाने पर निर्भर करता है, तो मैंने सोचा कि मैं कर सकता हूं

@pytest.mark.django_db(transaction=True)
@pytest.fixture(scope="session")
def object():
    object = Object.create_object(params)
    yield object
    // or alternatively
    object = mixer.blend('myObject')
    yield object

हालांकि, मुझे टेस्ट केस रन पर निम्न त्रुटि प्राप्त होती है: Database access not allowed, use the "django_db" mark, or the "db" or "transactional_db" fixtures to enable it.