التعامل مع تغييرات واجهة TDD

Question

لقد بدأت في استخدام TDD.كما ذكر في سؤال سابق أكبر صعوبة هي التعامل مع تغييرات الواجهة.كيف يمكنك تقليل التأثير على حالات الاختبار الخاصة بك مع تغير المتطلبات؟

Answer 1

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

في كثير من الأحيان عندما تتغير الواجهة، تجد أن "عددًا كبيرًا جدًا" من الاختبارات يتعطل، على سبيل المثال.تبين أن اختبارات الوظائف غير ذات الصلة إلى حد كبير تعتمد على تلك الواجهة.يمكن أن يكون ذلك علامة على أن اختباراتك واسعة جدًا وتحتاج إلى إعادة هيكلة.هناك العديد من الطرق المحتملة التي يمكن أن يحدث بها ذلك، ولكن إليك مثالًا نأمل أن يوضح الفكرة العامة بالإضافة إلى حالة معينة.

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

def test_add_item_to_order(self):
    acct = Account('Joe', 'Bloggs')
    shipping_addr = Address('123 Elm St', 'etc' 'etc')
    order = Order(acct, shipping_addr)
    item = OrderItem('Purple Widget')
    order.addItem(item)
    self.assertEquals([item], order.items)

الى هذا:

def make_order(self):
    acct = Account('Joe', 'Bloggs')
    shipping_addr = Address('123 Elm St', 'etc' 'etc')
    return Order(acct, shipping_addr)

def make_order_item(self):
    return OrderItem('Purple Widget')

def test_add_item_to_order(self):
    order = self.make_order()
    item = self.make_order_item()
    order.addItem(item)
    self.assertEquals([item], order.items)

هذا النمط بالذات هو طريقة الخلق.

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

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

Answer 2

أنا يفكر وهذا هو أحد أسباب الحجة الشائعة القائلة بأن الواجهات تُستخدم كثيرًا.

ومع ذلك، أنا لا أوافق.

عندما تتغير المتطلبات، يجب أن تتغير اختباراتك أيضًا.يمين؟أعني، إذا كانت المعايير التي كتبت الاختبار من أجلها لم تعد صالحة، فيجب عليك إعادة كتابة هذا الاختبار أو حذفه.

آمل أن يكون هذا مفيدًا، ولكن أعتقد أنني ربما أخطأت في فهم سؤالك.

Answer 3

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

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

Answer 4

في TDD، اختباراتك ليست اختبارات.وهي مواصفات قابلة للتنفيذ.آيو:فهي ترميز قابل للتنفيذ لمتطلباتك. دائماً ضع ذلك في الاعتبار.

والآن أصبح الأمر واضحًا فجأة:إذا تغيرت متطلباتك، الاختبارات يجب يتغير!هذا هو بيت القصيد من TDD!

إذا كنت تقوم بتنفيذ الشلال، فسيتعين عليك تغيير مستند المواصفات الخاص بك.في TDD، عليك أن تفعل الشيء نفسه، باستثناء أن المواصفات الخاصة بك ليست مكتوبة في Word، بل مكتوبة في xUnit.

Answer 5

"ما الذي يجب علينا فعله لمنع التعليمات البرمجية والاختبارات الخاصة بنا من التبعية للمتطلبات؟يبدو أن لا شيء.في كل مرة تتغير فيها المتطلبات، يجب علينا تغيير الكود والاختبارات الخاصة بنا.ولكن ربما يمكننا تبسيط عملنا؟نعم نستطيع.والمبدأ الأساسي هو:تغليف التعليمات البرمجية التي يمكن تغييرها."

http://dmitry-nikolaev.blogspot.com/2009/05/atch-your-changes.html

Answer 6

تكتب الاختبارات قبل أن تكتب الكود الخاص بالواجهة الجديدة.

Answer 7

إذا كنت تتبع نهج الاختبار أولاً، فمن الناحية النظرية لن يكون هناك أي تأثير لتغييرات الواجهة على رمز الاختبار الخاص بك.بعد كل شيء، عندما تحتاج إلى تغيير واجهة ما، عليك أولاً تغيير حالة (حالات) الاختبار لتتوافق مع المتطلبات ثم المضي قدمًا وتغيير واجهاتك/تنفيذك حتى تنجح الاختبارات.

Answer 8

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

يعد إجراء الاختبارات أمرًا جيدًا، وأي تغيير في التعليمات البرمجية الخاصة بك يجب أن يؤدي إلى تعطيل الاختبارات.

Answer 9

إذا تغيرت المتطلبات، فيجب أن تكون اختباراتك هي أول ما يتغير، وليس الواجهة.

سأبدأ بتعديل تصميم الواجهة في أول اختبار مناسب، وتحديث الواجهة لاجتياز الاختبار الجديد.بمجرد تحديث الواجهة لاجتياز الاختبار، من المفترض أن ترى توقف الاختبارات الأخرى (لأنها ستستخدم الواجهة القديمة).

يجب أن يتعلق الأمر بتحديث الاختبارات الفاشلة المتبقية بتصميم الواجهة الجديد حتى تتمكن من اجتيازها مرة أخرى.

سيؤدي تحديث الواجهة بطريقة تجريبية إلى ضمان أن التغييرات ضرورية بالفعل وقابلة للاختبار.