Pytest-django: ترتيب تنفيذ الاختبارات

لا أرى أسبابًا قوية جدًا لإعادة ترتيب الاختبارات ، لكنني لست ضدها حقًا سواء كان من السهل سحبها.

ومع ذلك ، فأنا أؤيد بشدة إجراء الاختبارات التي يمكن إجراؤها بأي ترتيب. في رأيي ، الاختبارات التي لا تنظف بعد نفسها أو الاختبارات التي تعتمد على الحالة من الاختبارات الأخرى معطلة وأعتقد أنه من الجيد أن تكون pytest-django غير متوافقة مع عداء اختبار Djangos في تلك الحالات.

فيما يلي بعض المناقشات الأساسية حول ترتيب الاختبارات في Django:
https://groups.google.com/forum/#!msg/django -developers / PfK0km66CNI / JbReB0pDkR8J
https://code.djangoproject.com/ticket/18271

انظر # 223.

ومع ذلك ، فأنا أؤيد بشدة إجراء الاختبارات التي يمكن إجراؤها بأي ترتيب.

يمكن القيام بذلك / اختباره باستخدام https://github.com/klrmn/pytest-random ، والذي يستخدم نفس خطاف pytest وبالتالي ربما يكون الطلب مهمًا عند استخدامه مع التصحيح من # 223.

ربما يمكننا إضافة pytest-random (أو الفكرة من هناك) إلى مجموعة اختبار Travis؟

ربما لا تكون مجموعة الاختبارات pytest-django نفسها آمنة بشكل عشوائي حقًا - فهناك بعض الاختبارات التي تتوقع نوعًا ما من النظام (على سبيل المثال ، جميع الاختبارات _ * _ الاختبارات مرة أخرى). أنا أعتبر هذه أخطاء ، ويجب بالتأكيد استبدال هذه الاختبارات باختبارات testdir.runpytest() المناسبة للتأكد من أنهم يختبرون الشيء الصحيح بالفعل.

أنا ضد إعادة ترتيب الاختبارات لتتوافق مع طلب Django ، فالطلب لا ينبغي أن يحدث أي فرق فيما يتعلق بالتوافق على أي حال. أعتقد أن إعادة ترتيب الاختبارات من الأفضل تركها لتختبر نفسها (التحسينات المستقبلية المحتملة من خلال أن تكون أكثر ذكاءً بشأن التخزين المؤقت للتركيبات ، إلخ) ، و pytest-random و pytest-xdist ، ما لم يكن هناك سبب قوي لتغيير الترتيب.

أشعر بالسوء حيال هذا لأنك بذلت الكثير من العمل في هذا وأنشأت رقعة لطيفة للغاية ، لكنني أعتقد أننا أفضل من خلال عدم دمج هذا.

ماهي أفكارك حول هذا؟

أنا شخصيا 1+ على هذا. أتفق معك pelme ، من الناحية المثالية ، لا ينبغي أن يكون الترتيب مهمًا. لكني هنا أحاول البحث عن كيفية إجراء اختبار يعمل بشكل جيد من تلقاء نفسه ولكنه يتعطل عند تشغيله بعد اختبار محدد آخر. لا يبدو هذا الوقت الإضافي الإضافي في تشغيل pytest-django جيدًا بالنسبة لي أو لا يبدو قراري بمحاولة التحول إلى pytest (في الوقت الحالي على أي حال ، أنا متأكد بمجرد أن أقوم بتشغيله وتشغيله سيُغفر الجميع) .

إذا كان من الممكن تجنب هذا الألم من جانبي من خلال اتباع نفس الترتيب مثل Django ، أعتقد أن هذا فوز صافٍ. سيسهل الأمر على مشاريع Django الحالية للتبديل ، حتى لو كانت بها أخطاء في مجموعات الاختبار الخاصة بهم والتي تم إخفاءها بالترتيب الذي ينفذ به عداء Django جناحهم.

على الرغم من أنها غير مثالية ، فهي عملية. حتى وجود خيار السماح بإعادة الطلب صراحة سيكون أمرًا رائعًا ، وبهذه الطريقة يمكنني أن أظهر لفريقي أنه عند التشغيل بالطريقة العادية ، يبدو كل شيء جيدًا ولكن ... قم بتبديل الترتيب وإلقاء نظرة على جميع الأخطاء المخفية التي لدينا في اختبارنا جناح!! ثم يمكننا التخطيط للوقت لمعالجة ذلك وإصلاحه مع عدم وجود هذا العائق في اعتمادنا لـ pytest و pytest-django.

على الأقل ، ليس من الصعب جدًا تنفيذ طلبك باستخدام pytest_collection_modifyitems .

كان التطبيق الذي أمتلكه لهذا هو أن مجموعة الاختبار الخاصة بي تحتوي على بعض تركيبات DB باهظة الثمن التي تم إعدادها لكل اختبار ، وكان مكسبًا هائلاً في الأداء (ربما 2-3x) لإعداد التركيبات أولاً ، ثم تشغيل كل اختبار ( تم تغليف كل واحدة بالفعل في معاملة) ، ثم قم بإجراء أي اختبارات تتطلب قاعدة بيانات للمعاملات (على سبيل المثال @ pytest.mark.transactional_db) في نهاية التشغيل التجريبي. على الرغم من تشغيل هذا الاختبار ، إلا أن إعادة ترتيب الاختبار كانت أسهل شيء ..

@ dan-passaro
هل جربت https://github.com/pytest-dev/pytest-django/pull/223؟

بالنظر إلى # 223 ، يبدو أنه يجب أيضًا التعامل مع فصول اختبار Django ، وليس فقط إلقاء نظرة على العلامات الخاصة بـ pytest.

وجدنا أنه بعد الترقية إلى Django 1.8 ، كانت اختباراتنا التي ورثناها من TransactionTestCase تتسبب في فشل اختباراتنا الأخرى بسبب إرجاع قاعدة البيانات إلى حالة فارغة بعد انتهاء TransactionTestCase.

إضافة serialized_rollback = صحيح لمثيلات TransactionTestCase الخاصة بنا سمحت بتشغيل هذه الاختبارات ، ولكن عندما يتم تشغيل اختبار آخر ورث من TestCase من Django بعد تشغيل TransactionTestCase ، فإنه سيفشل لأن قاعدة البيانات ستكون فارغة مرة أخرى.

أدت إضافة serialized_rollback = صحيح لجميع حالات الاختبار لدينا إلى إبطاء الأمور لدرجة أنه لم يكن خيارًا.

لذلك هناك آثار جانبية لعدم الحفاظ على نفس الترتيب.

هل هناك أفضل الممارسات التي ينبغي النظر فيها لتجنب هذه المشكلة؟

+1 على التعليق السابق من @ bparker98. نحن ننتقل من Django TestRunner إلى Pytest Django ، لكننا لم نعد كتابة كل ما لدينا من TestCase و TransactionTestCase إلى Pytest. عندما ينفذ Pytest مجموعتنا ، يتم مسح قاعدة البيانات بعد آخر معاملة (مع serialized_rollback = True). ثم يفشل TestCase التالي في كل مرة. قد لا تكون استراتيجية Django (تشغيل TestCase بالكامل ، ثم جميع TransactionTestCase) شيئًا يجب اتباعه على المدى الطويل ، ولكن بدونها ، يجلب Pytest الكثير من الانحدار (في حالتنا).

كنت أعاني من أجل تبديل مشروع قائم إلى pytest-django بسبب هذه المشكلة. لقد اتخذت نهج blueyed من https://github.com/pytest-dev/pytest-django/pull/223 ، ووسعته لدعم الفئات الفرعية لـ Django TransactionTestCase ، وحولتها إلى مكون إضافي ، ووضعتها على PyPI: https://pypi.python.org/pypi/pytest-django-ordering. إذا كنت تريد استخدام pytest-django مع الحفاظ على الترتيب الذي يدير به Django الاختبارات ، فيمكنك ببساطة تثبيت المكون الإضافي بجانب pytest-django .

تضمين التغريدة
شكرا.
هل تعتقد أنه سيكون من السهل دمجه بناءً على خيار؟

blueyed بالتأكيد ، سنحتاج فقط إلى إضافة خيار منطقي جديد إلى pytest_addoption (على سبيل المثال ، --django-ordering ) والتحقق منه قبل فرز الاختبارات المجمعة. ومع ذلك ، إذا لم يتم دمج https://github.com/pytest-dev/pytest-django/pull/223 ، فلست متأكدًا مما إذا كان سيتم دمجها أيضًا.

pelme هل https://github.com/pytest-dev/pytest-django/pull/223؟

لقد أصلحت / أعيد تأسيس https://github.com/pytest-dev/pytest-django/pull/223 الآن ، ويجب أن تكون جيدة كما هي في ذلك الوقت ، ولكن من التعليق (التعليقات) السابقة من rlucioni أعتقد ذلك يمكن / يجب أن تتحسن أكثر.

تضمين التغريدة
كيف هي تجربة البرنامج المساعد الخاص بك؟
هل ترغب في اعتماد https://github.com/pytest-dev/pytest-django/pull/223 ، وتحسينه حتى لا تكون هناك حاجة إلى المكون الإضافي الخاص بك بعد الآن؟

أود حقًا أن أرى هذا في pytest-django. ولكن لدعم pytest 3.6 ، عليك التفكير في https://github.com/rlucioni/pytest-django-ordering/issues/3

تضمين التغريدة
سيكون رائعًا إذا كان بإمكانك المساعدة في الحصول عليه في ذلك الوقت.

أعتقد أن الاختبار من https://github.com/pytest-dev/pytest-django/pull/223 يمكن استخدامه ، ثم يمتد الرمز من ما يفعله pytest-django-ordering.

أعتقد أنه يجب علينا التقصير في طلب اختبارات مثل Django ربما في ذلك الوقت - لست متأكدًا مما إذا كانت هناك حاجة إلى العلم (في البداية).

لم أقارن # 223 بالطلب pytest-django ، ولكن على الأقل يبدو أن TransactionTestCase مفقود (قائم على unittest).

قد يكون الأسلوب الجيد هو إنشاء علاقات عامة جديدة لهذا الأمر بعد ذلك ، وسنغلق رقم 223 بعد ذلك.

أعتقد أن rlucioni سيكون سعيدًا إذا قمنا

blueyed أعتقد أن طلب pytest-django يدعم TransactionTestCase . النهج المتبع هناك مشابه للنهج الموجود في https://github.com/pytest-dev/pytest-django/pull/223.

تجربة استخدام البرنامج المساعد جيدة. التثبيت سهل. إن إدراك أنك بحاجة إليها في المقام الأول هو أقل من ذلك. ليس لدي الوقت ولا الرغبة في تبني https://github.com/pytest-dev/pytest-django/pull/223. إذا رغبostcar في ذلك ، فأنا

تضمين التغريدة
شكرا لملاحظاتك!

دعونا نأمل أن تلتقطهاostcar - وإلا يبدو أنها مشكلة جيدة جدًا للأشخاص الذين يرغبون في المساهمة (نظرًا لوجود الكود بالفعل).

أود تقديم طلب السحب. لكنني ربما أحتاج إلى أسبوعين من الوقت بسبب أشياء أخرى.

أردت فقط إضافة +1 لهذا ؛ واجهت مشكلة الطلب أيضًا. كان الحل البديل الذي استخدمته هو إضافة ما يلي إلى conftest.py:

from django.test import TestCase
from django.test import TransactionTestCase


def pytest_collection_modifyitems(items):
    # Sort items to put transactional test cases at the end.
    items.sort(
        key=lambda item: int((
            issubclass(item.cls, TransactionTestCase)
            and not issubclass(item.cls, TestCase)
        ))
    )

الشيء المهم الذي يجب ملاحظته هو أن TestCase هي فئة فرعية من TransactionTestCase.

سيكون من الرائع لو أن pytest-django قد بني فيها.

الرجاء اختبار رقم 223 وتقديم الملاحظات هناك - سأقوم بدمج هذا قريبًا على ما أعتقد.