علامة خضراء لا تثبت صحة الاختبار

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

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

مشكلة أوراكل في فقرة واحدة

كل اختبار له نصفين. النصف الأول يفعل شيئا. الشوط الثاني يقرر ما إذا كانت النتيجة صحيحة. النصف الثاني هو الوحي، وهو النصف الذي يهم. تتحقق أوراكل ضعيفة من أقرب إشارة مرئية: إشعار، أو توقف الدوار، أو تغيير عنوان URL. تتحقق أوراكل قوية من النتيجة من اتجاه مستقل: السجل في قاعدة البيانات، واستجابة واجهة برمجة التطبيقات (API) التي تستدعيها الصفحة، والحالة بعد إعادة التحميل الجديدة.

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

لماذا تنجرف الاختبارات المكتوبة بالذكاء الاصطناعي نحو الأقوال الضعيفة؟

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

الانتظار التلقائي للكاتب المسرحي يجعل هذا الأمر أكثر أمانًا مما هو عليه الآن. تؤكد عمليات التحقق من قابلية التنفيذ أن العنصر مرئي ومستقر ويستقبل الأحداث قبل وصول النقرة. تنتظر تأكيدات إعادة المحاولة التلقائية الحالة المتوقعة. كلاهما يقلل من حالات الفشل المرتبطة بالتوقيت. ولا يسأل أي منهما عما إذا كانت الحالة هي الحالة الصحيحة. يمكن أن يكون الاختبار مستقرًا تمامًا وخاطئًا تمامًا.

ثلاث ترقيات أوراكل تعمل اليوم

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

تأكيد طبقة واحدة لأسفل. يمكن للكاتب المسرحي انتظار استجابة الشبكة التي تعتمد عليها واجهة المستخدم. قم بإقران تأكيد واجهة المستخدم مع expect(response).toBeOK() عند استدعاء واجهة برمجة التطبيقات (API) الذي يحفظ فعليًا، أو استعلم عن واجهة برمجة التطبيقات مباشرة بعد تدفق واجهة المستخدم وقارن القيمة المخزنة.

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

سؤال المراجعة الذي يغير كل شيء

إذا سمحت للوكلاء بكتابة الاختبارات والبشر بمراجعتها، فاقضِ وقت المراجعة في سؤال واحد لكل اختبار: ما الذي يؤكده هذا، وهل يمكن أن ينجح أثناء تعطل الميزة؟ مراجعة المسار السعيد هي قراءة الاختبار. مراجعة أوراكل هو اختبار الاختبار.

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

تخبرك علامة الاختيار الخضراء بإجراء الاختبار. لا يخبرك أبدًا أن الاختبار كان صحيحًا.