توقيت الاختبار
بالأمس، شرعت في إنشاء أداة للتهيئة التلقائية لـ Shadowsocks Outline، بهدف تحويلها إلى مشروع Python يمكن للآخرين استخدامه. قمت بتطوير برنامج نصي يقوم بتحديث ملف config.yaml بإعدادات وكيل Shadowsocks عن طريق فك تشفير عناوين URL الخاصة بـ Shadowsocks من ملف ssconfig. بالإضافة إلى ذلك، قمت بإنشاء برنامج نصي آخر يستخدم gsutil لتحميل ملف الاشتراك للعملاء إلى Google Cloud Storage.
لقد استخدمت Windsurf، وهو محرر أكواد يعتمد على الذكاء الاصطناعي، للمساعدة. ومع ذلك، واجه صعوبة في التعامل مع التبعيات الوهمية (mock dependencies) في اختبارات الوحدة (unit testing) باستخدام لغة Python.
عندما كنت أفكر في الدروس التي شاركها Yin Wang حول الاختبار، تذكرت تجاربه في Google، حيث عمل على مترجم Python وقام بفهرسة كود الشركة لوظيفة البحث. كان زملاؤه يصرون على كتابة الاختبارات، وهو ما وجده مزعجًا. كان يعتقد أن كتابة كود أنيق أهم من الاختبار، وأن زملاءه يفهمون فقط الجوانب السطحية دون استيعاب الجوهر.
لقد أدركت خطئي؛ الذكاء الاصطناعي لم يشير إليه. كان يجب عليّ التأكد من أن الكود الرئيسي للمكتبة يكون قويًا قبل التركيز على الاختبارات. ينطبق نفس المبدأ على مشروع إثبات المفهوم. في الوظائف السابقة، مثل بدء تشغيل خدمة مصغرة (microservice)، كان يجب كتابة الاختبارات بعد أن يكون للخدمة بعض واجهات برمجة التطبيقات (APIs) أو الوظائف.
إذا تعامل Windsurf مع جزء الاختبارات بشكل جيد، لما كان لدي هذا الشكوى. ومع ذلك، هناك مشكلتان متميزتان في اللعب: توقيت تنفيذ الاختبارات والطريقة الصحيحة لكتابتها. حاليًا، نحن نركز على الأول. هذه القضايا مترابطة إلى حد ما. إذا وجد محرر أكواد الذكاء الاصطناعي أو الإنسان سهولة في كتابة كود الاختبار، فقد يبدو توقيت الاختبارات تافهًا. ومع ذلك، فإن الجهد المطلوب لكتابة الاختبارات مماثل لكتابة الكود الرئيسي، مما يجعل التوقيت اعتبارًا مهمًا.
من منظور التعاون، يمكن أن يختلف النهج المتبع في الاختبار. بالنسبة لمشروع شخصي، قد أكتب كمية كبيرة من الكود قبل إنشاء الاختبارات. ومع ذلك، عند العمل ضمن فريق، من الأفضل عادةً كتابة اختبارات لكل جزء أو ميزة. ولكن هذا ليس هو الحال دائمًا؛ إذ يعتمد ذلك على كيفية تعاون الفريق. الطريقة الأكثر دقة لوصف ذلك هي أنه يجب كتابة الاختبارات للكود الذي يشاركه أعضاء الفريق مع بعضهم البعض. الهدف هو ضمان جودة الكود، لذا قبل تسليم الكود، يكون كل عضو في الفريق حرًا في اختيار توقيت الاختبارات الخاصة به.
في تجربة عمل سابقة، تعاونت مع ثلاثة مهندسين آخرين في مجال تطوير الواجهات الخلفية (backend) على ميزة استغرقت نصف عام لتسليمها. من منظور الاختبار، قد توضح النقاط التي تمت مناقشتها في هذه المقالة سبب بطء التطوير خلال ذلك الوقت.
من وجهة نظر التعاون، يجب أن يكون المسؤولون عن الكود الرئيسي مسؤولين أيضًا عن الاختبارات ذات الصلة. يجب أن تكون المهام متشابكة بأقل قدر ممكن، مع وجود مسؤوليات واضحة ومنفصلة لكل عضو في الفريق.
بالعودة إلى موضوع الاختبار، نجد أن محررات الأكواد الذكية تفتقر أيضًا إلى هذا النوع من التحسين، مما يسلط الضوء على مجال يحتاج إلى تحسين. هذا المبدأ لا يقتصر على هندسة البرمجيات فقط؛ بل هو ذو صلة أيضًا بالعتاد الصلب والمجالات الأخرى. الاختبار هو شكل من أشكال التحسين، وكما يقول المثل: “التحسين المبكر هو أصل كل شر.”
من الضروري أن نتذكر الهدف الرئيسي من العمل. بينما تكون العمليات والإجراءات أمرًا لا مفر منه، يجب أن نضع في اعتبارنا ما هو مهم حقًا.
المراجع:
- التطوير القائم على الاختبار (Test-Driven Development)، Yin Wang
- منطق الاختبار (The Logic of Testing)، Yin Wang