المواضع التي يجب أن يفحصها اختبار تطوير الويب بالذكاء الاصطناعي
| الحالة بين الخطوات | نموذج يُرسَل والقائمة خلفه لا تتحدث. ومرشِّح يبقى فاعلًا في شاشة لا معنى له فيها. |
| التوقيت | عرض يسبق وصول البيانات، أو طلب ينتهي بعد اختفاء المكوّن. |
| المستخدم الثاني | ملكية وإمكانية رؤية مفترَضتان من الجلسة التي بنت الميزة. |
لا شيء من هذا يظهر في فروق الكود، ولهذا لا تُجدي المراجعة الأسرع نفعًا. لكنه يظهر خلال ثلاثين ثانية من استخدام التطبيق وهو قيد التشغيل، ولهذا يجب أن يجري الفحص هناك.
لماذا لا تُغلق الاختبارات التي كتبها الوكيل الحلقة
الاختبارات المولَّدة إلى جوار التنفيذ تشترك معه في افتراضاته. فإذا كان الكود يفترض أن نقطة نهاية تُعيد مصفوفة فارغة بدل 404، أكّد الاختبار الافتراض نفسه ونجح. تحصل على تغطية بلا إشارة مستقلة.
الفحص الذي يُغلق الحلقة يجب أن يختبر المنتج المنشور مقابل السلوك المقصود، لا مقابل تصوّر الكود عن نفسه.
إبقاؤه سريعًا بما يكفي لاستخدامه فعلًا
خطوة تحقق تستغرق وقتًا أطول مما استغرقه بناء الميزة سيجري تخطيها، وعن حق. ثلاثة أمور تُبقيها متناسبة: غطِّ المسارات لا الشاشات، وأبقِ السلاسل قصيرة، وشغّلها على طلب السحب لا عند كل حفظ.
إبقاء الحلقة محكمة بما يكفي لاستخدامها
خطوة التحقق التي تبدو بطيئة يجري تخطيها، والتخطي هنا قرار عقلاني، ولذلك فإن الإيقاع لا يقل أهمية عن التغطية.
ثلاثة أمور تُبقيها متناسبة. غطِّ المسارات لا الشاشات، لأن المسار فحص واحد بينما الشاشة خمسة. واجعل كل مسار في أقصر طريق يظل قادرًا على التقاط عطل حقيقي، وهو عادةً ثلاث أو أربع خطوات لا عشر. وشغّل المجموعة الواسعة على طلب السحب، مع إبقاء فحص أو فحصين سريعين بما يكفي لتشغيلهما أثناء العمل نفسه.
هذا الفصل الأخير هو ما يغفل عنه الناس. فالفحص الذي تشغّله أثناء البناء والفحص الذي يحرس الدمج لهما وظيفتان مختلفتان، ومحاولة استخدام مجموعة واحدة للغرضين تجعلها إما أبطأ من أن تُشغَّل كثيرًا أو أرقّ من أن يُوثق بها.
إدخاله في الحلقة
يثبّت الإعداد مهارة التحقق داخل وكيل البرمجة، فيجري الفحص حيث يجري العمل بدل أن يكون مهمة منفصلة.
الطرفية
npm install -g @testsprite/testsprite-cli
testsprite setup
وإن كنت تفضّل ألّا تثبّت شيئًا، فلوحة التحكم تؤدي الغرض نفسه. وكل ما يستطيع سطر الأوامر فعله غير ذلك تجده في مستودع CLI.
GitHub App هو webhook تُعدّه من لوحة تحكم TestSprite. يستمع إلى حدث النشر الذي ينتجه مسار النشر لديك أصلًا، فلا يتغير شيء في مستودعك.
GitHub Actions يضع الخطوة داخل سير عملك الخاص، ويُضبط من الطرفية.
ما الذي يتحقق منه TestSprite ولا يستطيع الوكيل التحقق منه
التطبيق المنشور، مقابل ما قلت إنه يجب أن يحدث لا مقابل ما يفترضه الكود. وهذا الاستقلال هو بيت القصيد: الاختبارات المكتوبة إلى جوار التنفيذ تشترك معه في افتراضاته، فتوافقه حتى في المواضع التي يخطئان فيها معًا.
يثبّت الإعداد مهارة التحقق داخل وكيل البرمجة لديك، فيجري الفحص كجزء من إحداث التغيير. والخطوات مقاصد لا محدِّدات عناصر، ويعود الإخفاق في حزمة واحدة يستطيع الوكيل التصرف بناءً عليها، وهو ما يُبقي الإصلاح في الحلقة نفسها التي جرى فيها التغيير.
والنتيجة أن أعطال الحالة والتوقيت والمستخدم الثاني تُلتقط قبل الدمج لا على يد مستخدم، ودون خطوة تحقق تستغرق وقتًا أطول مما استغرقته الميزة.
هل يُبطئ هذا وتيرة التطوير؟
أقل مما يُبطئها التصحيح الذي يمنعه. فالمقارنة ليست مع كلفة صفرية، بل مع اكتشاف العيب نفسه بعد الإطلاق.
هل يستطيع الوكيل اختبار عمله بنفسه؟
يستطيع تشغيل الفحوص. أما الفحوص نفسها فيجب أن تنبع من السلوك المقصود لا من التنفيذ، وإلا فأنت تصحّح واجبك بنفسك.
وماذا عن الاختبارات التي ولّدها؟
احتفظ بها من أجل التغطية ولا تعدّها تحققًا مستقلًا. فهي متوافقة مع الكود بحكم نشأتها.
ما حجم التغطية المطلوب قبل الإطلاق؟
المسارات التي يُحرجك انكسارها، إضافة إلى كل ما يمس المال أو الصلاحيات. ووسّع انطلاقًا من الحوادث الفعلية.
هل يصلح هذا للتطوير المحلي؟
يمكن لتشغيلات الواجهة الأمامية الوصول إلى تطبيق على جهازك عبر نفق، فيكون الفحص متاحًا قبل نشر أي شيء.
البناء صار أسرع. وعلى الفحص أن يلحق به.
يحتاج اختبار تطوير الويب بالذكاء الاصطناعي إلى فحص مستقل يُجرى على المنتج قيد التشغيل، لأن الاختبارات المكتوبة إلى جوار التنفيذ تشترك معه في افتراضاته. غطِّ المسارات، وأبقِ الأمر متناسبًا، وشغّله على طلب السحب.