كبار المطورين واختبارات الوحدات - مطلوب؟هل يجوز لهم استخدام الخدم؟[مغلق]

Question

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

Answer 1

أود أن أزعم أنه من وجهة نظر TDD النقية (أي.واحد يعتقد أنه يجب كتابة اختبارات الوحدة قبل التنفيذ)، يجب أن يكتب كبار المطورين أكثر اختبارات وحدة من أتباع، لا أقل.

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

Answer 2

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

(صياغة محرجة بسبب الحياد بين الجنسين.)

Answer 3

الشخص الذي يكتب الاختبار = تحديد كيفية عمل النظام = "الرئيس"

الأشخاص الذين ينفذون الاختبارات هم من يطلق عليهم "الأذناب"

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

Answer 4

هل ينبغي إعفاء كبار المطورين من اختبار الوحدة؟

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

Answer 5

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

Answer 6

الجزء الأول (كبار المطورين واختبار الوحدة)

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

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

هناك ثلاثة مواقف يمكنني التفكير فيها، في أعلى رأسي، حيث يقوم شخص آخر بكتابة الاختبارات لك استطاع يكون مقبولا.

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

2. البرمجة المقترنة (نمط بينج بونج) -

   يكتب اختبار جديد ويرى أنه يفشل.
   ب تنفذ الرمز اللازم لاجتياز الاختبار.
   ب يكتب الاختبار التالي.
   أ ينفذها.

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

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

الجزء الثاني (تحفيز الناس على كتابة الاختبارات)

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

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

Answer 7

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

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

Answer 8

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

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

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

Answer 9

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

Answer 10

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

Answer 11

أنا لا أشترك في دين TDD، لكنني أرى قيمة كبيرة في اختبار الوحدة/إلخ، وأقوم بذلك كثيرًا أثناء قيامي بالبرمجة.

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

مع أخذ ذلك في الاعتبار، لن تحصل على قيمة كبيرة من قيام "الأتباع" بكتابة الاختبارات لأنه

1. لن يكون لديهم فهم متعمق لجميع حالات الزاوية الدقيقة
2. لن يهتموا بالكود لأنهم لا يستثمرون فيه شيئًا
3. سيشعرون أنهم يعاملون مثل البلهاء.

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

Answer 12

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

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

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

Answer 13

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