A First Look at the Self-Admitted Technical Debt in Test Code: Taxonomy and Detection

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

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

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

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

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

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