التطوير القائم على الاختبار: تجنب أخطاء التنفيذ
نفذت العديد من فرق البرمجيات التطوير القائم على الاختبار (TDD) لتقليل إعادة العمل والتكاليف المرتبطة بها.
الأساس المنطقي: كلما اكتشفت مشكلة في دورة حياة تطوير البرامج (SDLC) في وقت مبكر، كلما كانت تكلفة إصلاحها أقل.
فيما يلي ملخص للفوائد والعيوب والعوائق التي تحول دون اعتماد TDD وأخطاء التنفيذ الشائعة.
فرضية TDD: تكتب الاختبار قبل أن تكتب الكود
مع TDD، يكون الاختبار في طليعة أذهان الناس أثناء تصميم المنتج وتصميمه وتطويره. يحدد مطورو البرامج مقدمًا ما يجب اختباره وكيفية اختباره.
ما الذي يجب على الميزة (الكود) القيام به بنجاح حتى تعتبر كاملة؟ ما هي الاختبارات التي يجب اجتيازها حتى يطلق عليها اسم جيد؟
يكتب المطورون هذه الاختبارات واحدًا تلو الآخر، بدءًا بحالة سهلة وبناء التعقيد من هناك، قبل ترميز الميزة. يتيح ذلك للمطورين التأكد من تغطية كل السيناريوهات المحتملة.
يجب أن تجتاز الميزة الاختبارات القديمة والجديدة قبل أن يربطها المطور بقاعدة التعليمات البرمجية.
كيف يختلف TDD عن أساليب التطوير السابقة؟
قبل TDD، كتب المطورون التعليمات البرمجية وكتب ضمان الجودة الاختبارات. وكانت هذه الوظائف صوامع.
حتى داخل فريق واحد، استخدم المطورون معايير متنوعة لتحديد متى يتم إرسال التعليمات البرمجية إلى القاعدة. شعر بعض المطورين أن الاختبار هو مهمة ضمان الجودة بنسبة 100 بالمائة.
أراد آخرون التأكد من عمل الكود الخاص بهم قبل إرساله إلى ضمان الجودة. قرر المطور الفردي مقدار الاختبار الذي يجب القيام به (أو عدم القيام به).
وأدى ذلك إلى عدم اتساق مستويات الجودة الناتجة عن التطوير، مما أدى إلى إعادة صياغة كبيرة، مما أثر على الجداول الزمنية والميزانيات.
ما هي فوائد اعتماد TDD؟
TDD أقل تكلفة من النهج المنعزل. لماذا؟ عندما يضيف المطورون تعليمات برمجية جديدة إلى القاعدة، تعمل التعليمات البرمجية ولا تكسر القاعدة.
شعار TDD “ابقها خضراء” يعني أن نتيجة الاختبار تكون دائمًا خضراء قبل إرسال الكود إلى القاعدة (حيث يؤثر على الآخرين). إذا لم يكن باللون الأخضر، فسيستمر المطور في العمل على الكود وهو في قمة أولوياته حتى يجتاز الاختبار.
إن نهج الصومعة، حيث يقوم المطورون بإلقاء التعليمات البرمجية فوق الحائط إلى ضمان الجودة، يعني أن المبرمجين قد انتقلوا بالفعل إلى وظائف جديدة عندما يجد ضمان الجودة أخطاء.
يمكن أن يكون للتأخير في العثور على الأخطاء عواقب لاحقة – أي شيء يتم إنشاؤه لاحقًا ويعتمد على الكود الإشكالي قد يحتاج أيضًا إلى إعادة صياغة.
فائدة أخرى: الاختبارات توثق الكود. عندما تقرأ اختبارًا، فإنك تفهم ما يجب أن تفعله التعليمات البرمجية، حتى تتمكن من التحقق من أنه يعمل بشكل صحيح.
هل هناك أي سلبيات؟
يرى بعض المديرين أن TDD يستغرق وقتًا أطول ويشعرون بالقلق بشأن مدى تأثير ذلك على الجداول الزمنية لشحن الوظائف الجديدة.
صحيح أن TDD يتطلب وقتًا إضافيًا عند إنشاء الميزات. أصبح لدى مطوري البرامج الآن تعليمات برمجية (اختبارات) إضافية للكتابة والصيانة.
ومع ذلك، يستفيد المديرون التنفيذيون من اتخاذ وجهة نظر طويلة الأمد. من خلال قضاء المزيد من الوقت على الواجهة الأمامية لـ SDLC، من الممكن تقصير SDLC بالكامل بشكل كبير.
بالإضافة إلى ذلك، يعمل TDD على تحسين جودة إصدارات البرامج، مما قد يؤدي إلى زيادة رضا العملاء وزيادة الإيرادات.
جانب سلبي آخر: قد تتطلب جهود تطوير المنتج المعقدة كتابة أطر عمل إضافية خاصة لاختبار كيفية تفاعل المنتج مع أدوات وأدوات مساعدة تابعة لجهات خارجية.
إذا كانت لديك أداة مساعدة قمت بتخصيصها بطريقة معينة، فستحتاج إلى إنشاء اختبارات للتأكد من أن منتجك يستخدم الأداة المساعدة بشكل صحيح.
العوائق الشائعة أمام اعتماد TDD
أكبر العوائق التي تحول دون التبني هي الثقافة الهندسية وتفضيلات المطورين الفرديين والضغط لإيصال المنتجات إلى السوق بسرعة.
في بعض المنظمات، يتطلب TDD تحولًا كبيرًا في العقلية. يمكن لخبير إدارة التغيير قياس درجة حرارة الفريق الهندسي لتحديد مدى الانفتاح على TDD ومجالات المقاومة والمخاوف.
في بعض الأحيان، يقول كبار المطورين: “الاختبار ليس وظيفتي. قوتي الخارقة هي خلق أشياء جديدة، ولا أريد أن أتباطأ من خلال كتابة الاختبارات.
يرفض بعض المديرين استخدام TDD، حيث يشعرون أن ذلك سيبطئ سرعة فريقهم. إنهم يريدون منتجًا قويًا وعالي الجودة ولكنهم في بعض الأحيان يكونون على استعداد لاتخاذ اختصارات للحصول على منتج خارج الباب.
ولتنفيذ TDD بنجاح، لا يمكن للإدارة أن تسمح باستمرار المواقف النخبوية والسرعة بأي ثمن.
يحتاج قادة الهندسة إلى وضع توقعات بأن جميع المطورين – حتى المهندسين المعماريين – مسؤولون عن الاختبار وجودة التعليمات البرمجية.
إذا كان المهندس المعماري يكتب كود الإنتاج، فإن المهندس المعماري يكتب الاختبارات. يمكن أن يساعد التدريب في جعل جميع أعضاء الفريق على نفس الصفحة ووضع القواعد الأساسية للاختبار التي يجب على الجميع اتباعها.
تتساءل بعض المنظمات أيضًا عن كيفية تنفيذ TDD في المشاريع القديمة. في هذه الحالة، ابدأ بالميزات الجديدة. وبعد ذلك، عند إعادة بناء أجزاء من التعليمات البرمجية القديمة، قم بإضافة اختبارات للأجزاء المعاد هيكلتها حديثًا.
ما الأخطاء التي ترتكبها المنظمات عند تنفيذ TDD؟
هناك ثلاثة أخطاء شائعة يمكن للقادة تجنبها بالتخطيط والتواصل الصحيحين:
- كتابة كود اختبار غير دقيق: يحتاج مطورو البرامج إلى التعامل مع كود الاختبار وأدوات الاختبار المساعدة كرمز على مستوى الإنتاج. سيظل الاختبار صالحًا طالما كان رمز الإنتاج، لذا يجب أن يكون مكتوبًا بشكل جيد. إن اتباع الاختصارات يمكن أن يعود عليك بالضرر في المستقبل.
- نقل الاختبار إلى الموظفين المبتدئين: تقوم العديد من المنظمات بتعيين مهندسين جدد للاختبار وكبار الموظفين في الإنتاج. في TDD، يعد الاختبار بنفس أهمية الترميز ويحتاج إلى إشراف من المطورين ذوي الخبرة الذين يمكنهم اكتشاف المشكلات بسرعة. مع نمو قاعدة التعليمات البرمجية وتصبح أكثر تعقيدًا، فأنت بحاجة إلى شخص يعرف ما الذي تبحث عنه وكيفية تنظيم التعليمات البرمجية. لا يتمتع المبرمجون الجدد في حياتهم المهنية بالخبرة اللازمة للقيام بذلك بفعالية، ويمكن أن ينتهي بك الأمر إلى حالة من الفوضى.
- السماح للاختبارات المعطلة بالبقاء معطلة: ابحث عن المبرمج البراغماتي أو اقرأ كتاب مالكولم جلادويل، نقطة التحول. يقدم كلاهما أمثلة على كيف يمكن لتجاهل شيء سيء أن يتحول إلى مشكلة أكبر. تسمح بعض الفرق بكسر الاختبارات ثم تتركها مكسورة، وتجري بسرعة تلو الأخرى. يتفاقم الضرر الناتج عن هذا الأسلوب مع مرور الوقت، وكلما طالت مدة السماح بذلك، أصبح إصلاحه أكثر تكلفة واستهلاكًا للوقت.
TDD يحل القيود البشرية
يستخدم طيارو الخطوط الجوية قوائم المراجعة المبدئية للتخلص من إمكانية إغفال أو نسيان شيء مهم. يخدم TDD غرضًا مشابهًا.
قبل TDD، ربما يكون المطور قد اختبر الكود يدويًا، وحدد أنه تم اجتيازه وإرساله إلى قاعدة الكود. ولكن في كثير من الأحيان كان هناك بعض التفاعل الذي لم يفكر المطور في اختباره.
أدى إرسال الكود إلى تعطيل القاعدة أو تسبب في عدم عمل الميزات الأخرى بشكل صحيح.
يتم تنفيذ أسطر التعليمات البرمجية بناءً على المواقف المختلفة.
لا يستغرق الأمر وقتًا طويلاً للوصول إلى النقطة التي لا يستطيع فيها المطورون الاحتفاظ بجميع الأكواد والسيناريوهات التي من المفترض أن يتعامل معها الكود في رؤوسهم.
إذا كان هناك عدة أشخاص في الفريق يساهمون في قاعدة التعليمات البرمجية، فلن يتمكن أي فرد من تتبع جميع الطرق التي يتفاعل بها البرنامج.
يقوم TDD بإجراء كافة الاختبارات، القديمة والجديدة، على أي كود جديد. تتفاعل بعض الاختبارات مع الكود الجديد، والبعض الآخر لا يفعل ذلك.
لكن لا يتعين على المطورين الاحتفاظ بهذه المعلومات في رؤوسهم، مما يقلل من الأخطاء البشرية والسهو. يحرر TDD الذاكرة العاملة للمطورين للقيام بأنشطة مهمة أخرى لحل المشكلات.
إذا كان الاختبار باللون الأخضر، فهذا يعني أن المطورين يعرفون أن الكود الخاص بهم يعمل بشكل صحيح ولم يتعطل أي شيء. تؤكد هذه الاختبارات أن الوظائف القديمة والجديدة تعمل بشكل صحيح.
المصدر: pluralsight
شاهد المزيد:
