توليد الاختبارات الآلية والمحددات (Locators) بالشبكات العصبية في مشروع قديم (Legacy): تجربة عملية
خلصت الكاتبة في مقالها السابق إلى أن توليد الاختبارات الآلية في مشروع قديم (Legacy) كبير، من دون ملف README يصف بنية إطار الاختبار، يتحول إلى حلقة لا تنتهي من المراجعات والتعديلات. في المقال الجديد، تشرح كيف ولّدت الاختبارات الآلية والمحددات بالضبط، وكم من الوقت استغرق ذلك، وأين ظل النموذج يخطئ رغم كل شيء، وهل تستحق النتيجة العناء.
معالج بواسطة الذكاء الاصطناعي من Habr AI؛ بتحرير Hamidun News
تواصل الكاتبة سلسلتها العملية عن التوليد الآلي للاختبارات. وتشرح في المقال الجديد كيف ولّدت بالضبط الاختبارات الآلية والمحددات لمشروع قديم (Legacy) كبير، وكم من الوقت استغرق ذلك، وأين أخطأ النموذج، وهل كان الأمر يستحق العناء.
ما الذي أظهره الجزء السابق من السلسلة
خلص مقال الكاتبة السابق إلى نتيجة أساسية: من دون ملف README يصف بنية إطار الاختبار، يتحول توليد الاختبارات الآلية في مشروع قديم كبير إلى حلقة لا تنتهي من المراجعات والتعديلات. فالنموذج الذي لا يملك سياقًا عن بنية الإطار، أي الفئات الأساسية التي ينبغي استخدامها، وكيفية تنظيم المحددات، والاصطلاحات المعتمدة في المشروع، يقترح شيفرة تتكرر الحاجة إلى إعادة كتابتها يدويًا، بدلًا من الحصول على نتيجة صالحة للعمل من المرة الأولى.
يحدد هذا الاستنتاج إطار المقال الجديد: إذا تحقق الشرط الأساسي، أي وجود وصف للبنية، فإن السؤال التالي يتعلق بالممارسة. ومن هنا تبدأ الكاتبة مقالها الجديد، واعدةً بعرض عملية توليد الاختبارات الآلية والمحددات على شيفرة حقيقية، لا نصائح مجردة.
أين يتعثر توليد المحددات عادةً
تُعد المحددات على الأرجح أضعف حلقة في التوليد الآلي لاختبارات واجهة المستخدم (UI)، لأنها مرتبطة بترميز صفحة بعينها، وهو في المشاريع القديمة كثيرًا ما يكون غير مستقر وغير متسق وغير موثّق. وحين يولّد النموذج المحددات من دون فهم عميق لبنية DOM الفعلية للشاشة المعنية، فإنه قد يقترح محددات هشة تنكسر عند أدنى تغيير في التصميم، أو يكرر محددات موجودة أصلًا في المشروع بدلًا من إعادة استخدام الجاهز منها.
لذلك تركز الكاتبة في المقال الجديد على ثلاثة أسئلة عملية: كم من الوقت يوفره هذا النهج فعليًا مقارنةً بالكتابة اليدوية؟ وفي أي السيناريوهات يواصل النموذج الخطأ حتى مع وجود README يصف البنية؟ وهل يثبت هذا النهج جدواه على نطاق مشروع قديم كبير، حيث يتمثل ثمن الأخطاء في الاختبارات في إنذارات كاذبة في CI وإضاعة وقت الفريق في تحليلها؟
- الصيغة: المقال الثاني في سلسلة عن توليد الاختبارات الآلية والمحددات بالذكاء الاصطناعي
- الشرط من المقال الأول: ملف README يصف بنية الإطار إلزامي في المشروع القديم
- محور المقال الجديد: العملية الفعلية والوقت المستغرق والأخطاء النموذجية للنموذج
- موضوع الاختبار: مشروع قديم (Legacy) كبير
ماذا يعني ذلك
تُظهر تجربة سلاسل مقالات كهذه أن توليد الاختبارات الآلية بمساعدة الذكاء الاصطناعي لا يقتصر عمليًا على «طلبتُ فحصلتُ على شيفرة تعمل». فهو يتطلب عملًا تحضيريًا على سياق المشروع، وتقييمًا واقعيًا للسيناريوهات التي يتحقق فيها توفير الوقت فعلًا، وتلك التي يُستهلك فيها هذا التوفير في المراجعة اليدوية وتعديل الشيفرة المولّدة.
أسئلة وأجوبة حول الخبر
ما أبرز التفاصيل حول ما الذي أظهره الجزء السابق من السلسلة؟
خلص مقال الكاتبة السابق إلى نتيجة أساسية: من دون ملف README يصف بنية إطار الاختبار، يتحول توليد الاختبارات الآلية في مشروع قديم كبير إلى حلقة لا تنتهي من المراجعات والتعديلات. فالنموذج الذي لا يملك سياقًا عن بنية الإطار، أي الفئات الأساسية التي ينبغي استخدامها، وكيفية تنظيم المحددات، والاصطلاحات المعتمدة في المشروع، يقترح شيفرة تتكرر الحاجة إلى إعادة كتابتها يدويًا، بدلًا من الحصول على نتيجة صالحة للعمل من المرة الأولى. يحدد هذا الاستنتاج إطار المقال الجديد: إذا تحقق الشرط الأساسي، أي وجود وصف للبنية، فإن السؤال التالي يتعلق بالممارسة. ومن هنا تبدأ الكاتبة مقالها الجديد، وا
ما أبرز التفاصيل حول أين يتعثر توليد المحددات عادةً؟
تُعد المحددات على الأرجح أضعف حلقة في التوليد الآلي لاختبارات واجهة المستخدم (UI)، لأنها مرتبطة بترميز صفحة بعينها، وهو في المشاريع القديمة كثيرًا ما يكون غير مستقر وغير متسق وغير موثّق. وحين يولّد النموذج المحددات من دون فهم عميق لبنية DOM الفعلية للشاشة المعنية، فإنه قد يقترح محددات هشة تنكسر عند أدنى تغيير في التصميم، أو يكرر محددات موجودة أصلًا في المشروع بدلًا من إعادة استخدام الجاهز منها. لذلك تركز الكاتبة في المقال الجديد على ثلاثة أسئلة عملية: كم من الوقت يوفره هذا النهج فعليًا مقارنةً بالكتابة اليدوية؟ وفي أي السيناريوهات يواصل النموذج الخطأ حتى مع وجود README يصف
ما أبرز التفاصيل حول ماذا يعني ذلك؟
تُظهر تجربة سلاسل مقالات كهذه أن توليد الاختبارات الآلية بمساعدة الذكاء الاصطناعي لا يقتصر عمليًا على «طلبتُ فحصلتُ على شيفرة تعمل». فهو يتطلب عملًا تحضيريًا على سياق المشروع، وتقييمًا واقعيًا للسيناريوهات التي يتحقق فيها توفير الوقت فعلًا، وتلك التي يُستهلك فيها هذا التوفير في المراجعة اليدوية وتعديل الشيفرة المولّدة.
Ship AI Faster with Founders, Engineers & Weekly Architecture Reviews
Inside Vibe Club (hamidun.com/club) — weekly live masterminds with Zhemal Khamidun, Tech Radar, full LMS access, and 370+ production Claude Code skills.
أهم ما في عالم الذكاء الاصطناعي — مرة كل أسبوع
سبع قصص مهمة فعلاً هذا الأسبوع، مختارة بعناية. بلا ضجيج ولا بيانات صحفية.
تم! تحقق من بريدك للتأكيد.