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