بعض الأسئلة حول اختبارات الوحدة

Question

سؤالان حول اختبارات الوحدة.

1. لقد كنت أكتب اختبارات الوحدة لفترة من الوقت ، ومع ذلك فهي عادة لاختبار الفصول التي كتبتها بالفعل. قرأت مؤخرًا مقالة(ضع في اعتبارك مقالة قديمة) تقول إنه يجب عليك كتابة اختبارات الوحدة قبل البدء في كتابة الكود الخاص بك.

   هل يتبع أي شخص هذه المنهجية بالفعل؟ يبدو أنها فكرة جيدة على الورق ، ولكن في الممارسة العملية؟

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

Answer 1

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

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

Answer 2

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

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

Answer 3

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

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

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

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

Answer 4

هل يتبع أي شخص هذه المنهجية بالفعل؟

نعم.

يبدو أنها فكرة جيدة على الورق ، ولكن في الممارسة العملية؟

نعم.

هل يجب أن تكتب اختبارات الوحدة لمعرفة كيف تتعامل طريقتك مع المدخلات السيئة/الضارة؟

نعم.

ماذا عن الوظائف التي لا ينبغي أبدًا تمرير هذا النوع من المدخلات إليهم؟ في أي نقطة ترسم الخط؟

عندما ينتقل من البرمجيات إلى الذهان.

يمكنك - إذا كنت تريد - كتابة اختبارات لمواقف مستحيلة. ومع ذلك ، فأنت تضيع وقتك وصاحب العمل بطريقة واضحة.

تكتب اختبارات ل مُعرف استخدم حالات. وهذا كل شيء.

أنت لا تشكل حالات اختبار عشوائية بناءً على خيالك.

ماذا إذا؟ ماذا لو مُعرف حالات الاستخدام غير مكتملة؟ المشكله. تكتب اختبارات للواجهة الرسمية والتعاقدية العامة - ولا شيء أكثر من ذلك.

ماذا لو كان التصميم غير كافٍ وأدركت أن الواجهة المعطاة مليئة بالمواصفات غير المكتملة والتناقضات والثقوب الأمنية؟ هذا لا علاقة له بالاختبار. هذا مجرد برمجة. التصميم السيئ هو تصميم سيء.

ماذا لو أخذ بعض sociopath الضار الكود الخاص بك ويستخدمه بطريقة تتجاوز (أو تفشل في تلبية) المواصفات المحددة؟ المشكله. يفوز Sociopath. لقد تمكنوا من وضع الكود الخاص بك في الموقف المستحيل الذي لم تختبره. شراء لهم بيرة لكونها ذكية جدا.

Answer 5

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

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

Answer 6

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

إذا قمت بعمل رمز Unittest "مدفوع البيانات" ، فلا ينبغي أن يهم إذا كان الكود يختبر الإدخال "السيئ" أو "الجيد". ما يهم هو أن لديك مجموعة بيانات كبيرة بما يكفي تغطي كليهما.