سؤال

أنا أتعاون مع مجموعة من المحترفين لتنظيم حدث للمساعدة في تعليم ممارسة TDD للأشخاص المهتمين، ولكن ليس لديهم خبرة (المبتدئين).

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

ماذا تقول أنه يجب علينا أن نجعل من أولوياتنا التعلم؟أي جانب من جوانب تدريس TDD هو ال الأهم.إذا كان عليك القيام بشيئين، فلا بأس، لن ألزمك بالجزء الفردي :)

هل كانت مفيدة؟

المحلول

يتعلق الأمر بالتصميم.إنه لا حول الاختبارات.

نصائح أخرى

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

أحمر - أخضر - عامل إعادة البناء -> فقط افعل ذلك.

مجرد نجاح اختباراتك لا يعني أن الكود صحيح.

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

لا أعرف ما إذا كان هذا يعتبر الشيء الأكثر أهمية - لكنه كان شيئًا استغرق مني بعض الوقت "لأدركه" عندما كنت أستكشف استخدام TDD لأول مرة.

لا تكتب الرمز في رأسك قبل كتابة الاختبار.

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

عندما كنت أفعل هذا لم أكن أفعل TDD حقًا - لأنني كنت أكتب الكود أولاً (حتى لو كان الكود في رأسي فقط :-)

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

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

وأنا أتفق مع ما قال جون في إجابته, ، لكنني أعتقد أن النتيجة الطبيعية المهمة هي أن قابلية الاختبار لا تملي "تصميم جيد", ، ولكنه مجرد مؤشر على أن تصميمك يحقق الهدف.

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

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

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

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

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

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

المضي قدما في خطوات الطفل.

تأكد من أن اختباراتك لا تغطي سوى نطاق صغير جدًا، وكما يقول PhlipCPP:'قم بإجراء الحد الأدنى من التعديل اللازم لنجاح الاختبار.'

ومع ذلك، هناك الكثير لـ TDD، لذلك لا يزال يتعين عليك التأكد من عدم تفويت أي شيء.

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

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

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

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

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top