اختبر تطبيقك في المتصفح بأمر واحد

اكتب /test في دردشة المشروع فيختبر Mythex تطبيقك كما يفعل شخص حقيقي: يفتح المعاينة الحية في متصفح، ويزور الصفحات، وينقر الأزرار، ويملأ النماذج، ثم يُبلغ في الدردشة بما نجح وما فشل. يمكنك توجيهه إلى مسار محدد، مثل «اختبر التسجيل وصفحة الأسعار»، أو تترك له المسار الواضح عبر التطبيق.

ما الذي يفعله؟

يمارس اختبار التطبيق المعاينة الحية لا الكود وحده. يشغّل Mythex متصفحاً على التطبيق الذي يعمل، ويلتقط ما يراه، بما في ذلك لقطات الشاشة حين تكون مفيدة، ثم يكتب ملخصاً للنتائج في الدردشة.

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

لماذا يفيد؟

عندما تبني مع وكيل، تكون المعاينة هي طريقتك للحكم على التقدم. تنقر هنا وهناك، فيبدو كل شيء جيداً، فتنتقل. لكن النقر على كل مسار بعد كل تغيير مُرهِق، وسهل أن تتفقد الصفحة التي غيّرتها للتو وتفوتك الصفحة التي كسرتها بهدوء.

يحوّل الاختبار سؤال «هل ما زال يعمل؟» إلى رسالة واحدة. تصف المسار المهم، فيسلكه الوكيل، وتحصل على تقرير يمكنك التصرف بناءً عليه. ولأنه يعمل في الدردشة نفسها، فالإصلاح على بُعد رسالة واحدة.

كيف تشغّله

1. تأكد من أن المعاينة تعمل وتعرض تطبيقك. الاختبار يعمل على المعاينة، فإذا كانت فارغة أو لا تزال تبدأ، انتظر أو أصلح ذلك أولاً.
2. اكتب /test في دردشة المشروع. يمكنك أيضاً أن تطلب بلغة عادية، فعبارة «اختبر التطبيق في المتصفح» تعمل كذلك.
3. حدد ما الذي تريد التركيز عليه، إن أردت. مثلاً: «اختبر التسجيل وصفحة الأسعار»، أو «أنشئ حساباً، وأضف عنصراً، ثم ادفع».
4. اقرأ التقرير. يلخص Mythex ما جرّبه وما الذي سار على نحو خاطئ، مع لقطات شاشة حيث تفيد.
5. أصلح ما وجده باستخدام /fix أو برسالة Build عادية.
6. شغّل /test مرة أخرى للتأكد من أن الإصلاح نجح ولم ينكسر شيء آخر.

متى تستخدمه؟

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

كيف تحصل على نتائج جيدة

كلما كان الطلب أوضح، كان التقرير أنفع.

• صِف المسار السعيد. «أنشئ حساباً، وأضف عنصراً، وادفع» يعطي الوكيل تسلسلاً واضحاً يتبعه ونتيجة واضحة يتحقق منها. أما «اختبر كل شيء» فتترك له أن يخمّن ما يهم.
• سمِّ الصفحات أو الميزات التي غيّرتها. إذا أعدت تصميم صفحة الأسعار للتو، فقل ذلك.
• اختبر على دورات صغيرة. غيّر شيئاً، واختبره، وأصلحه، واختبره مرة أخرى. من الأسهل أن ترى ما تعطّل عندما يتغير شيء واحد فقط.
• اقرنه بنقاط الحفظ. إذا كان تغيير ما قد أفسد أكثر مما أصلح، يمكنك الرجوع إلى آخر دور سليم بدلاً من الترقيع فوقه.

القيود

• يختبر المعاينة، لا موقعك المنشور. يعمل الاختبار على المعاينة الحية في مساحة عملك الخاصة. لن يفحص النسخة التي يراها الزوّار على عنوانك المنشور. انشر بشكل منفصل عندما تكون مستعداً.
• يجب أن تكون المعاينة تعمل. إذا لم تكن قائمة، فلا يوجد ما يُختبر.
• يتبع المسارات التي توجهه إليها. الطلب المركّز يحصل على فحص مركّز؛ وهو ليس مجموعة اختبارات شاملة.
• يُبلغ، والقرار لك. يخبرك الاختبار بما هو معطل. الإصلاح خطوة منفصلة، عبر /fix أو رسالة Build.

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

صفحة الوثائق تحتوي التفاصيل: اختبار التطبيق.