كيفية إقناع راعي المشروع بأن جميع الوظائف في الكود الخاص بك يجب أن تحتوي على اختبارات وحدة [مغلق]

Question

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

Answer 1

أفضل طريقة هي عدم التعامل مع الأشخاص "غير التقنيين" بهذه الطريقة.فقط قم بإدراجه في وقت التسليم دون الخوض في التفاصيل.

على الجانب الآخر، يبدو أن المواعيد النهائية للمشروع لم تكن واقعية لبنائه فعليًا.

Answer 2

أنا فقط كتب مطولا حول هذا الموضوع بالذات.

لتلخيص حججي ضد الشكاوى الشائعة:

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

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

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

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

Answer 3

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

Answer 4

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

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

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

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

Answer 5

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

Answer 6

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

Answer 7

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

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

Answer 8

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

Answer 9

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

من الواضح أن هناك الكثير من الطرق التي يمكنك اتباعها لبيع الاستقرار المتزايد، ولكن الدعم الفني هو تكلفة "مالية حقيقية" يرغب معظم المديرين في خفضها.