شغّل الاختبارات تلقائيًا مع كل عملية نشر على GitHub.
اربط مستودعًا مرة واحدة، وسيستمع TestSprite لحدث GitHub الذي يعني «تم نشر البناء الجديد والرابط أصبح مباشرًا (live)» — ثم يُشغّل مجموعة اختباراتك عليه وينشر النتيجة كتعليق على طلب السحب أو كفحص commit. دون ملف سير عمل، ودون تغييرات على خط الأنابيب لديك.
يعمل مع أي مزوّد ينشر إلى GitHub
يُشغَّل بواسطة CI/CD لديك
عملية نشر، أو تشغيل سير عمل، أو فحص حالة — عيّن حدث CI/CD الذي تملكه بالفعل كإشارة تعني «جاهز للاختبار».
تصل النتائج إلى طلب السحب
النجاح/الفشل، والخطوات الفاشلة، ورابط إعادة التشغيل تُنشَر كتعليق على طلب السحب أو فحص commit — يرى المراجعون الجودة جنبًا إلى جنب مع الكود.
اضبط الدمج ببوابة فحص حالة
فعّل «حظر طلب السحب حتى تنجح الاختبارات» وسيوقف فحص إلزامي عمليات الدمج طالما هناك تراجعات مفتوحة.
بلا أي تغييرات في ملفات سير العمل
كل شيء يُهيّأ داخل TestSprite. يبقى مستودعك، و.github/workflows، وخط الأنابيب الحالي لديك دون أي مساس.
1. يبني خط أنابيب CI/CD الخاص بك تطبيقك وينشره
→ وينتج عن ذلك حدث نشر في GitHub
2. يستقبل TestSprite ذلك الحدث عبر
تكامل GitHub App
3. يحدد TestSprite عنوان URL المستهدف — من
عملية النشر نفسها، أو من نمط عنوان URL تحدده أنت
(يدعم {pr}، {branch}، {branch-slug}، {sha})
4. يشغّل TestSprite اختباراتك وينشر النتائج
كتعليق على طلب السحب أو كفحص على الـ commit في GitHub
أطلق النشر بإشارة يمكنك الوثوق بها
تُختبر كل عملية نشر — معاينة طلب سحب أو دمج إلى بيئة staging — على الرابط الحقيقي المباشر. لا محاكاة، ولا تخمين.
طريقتان لتشغيل الاختبار
طلب السحب (Pull Request)
الأفضل لاكتشاف التراجعات قبل الدمج. يختبر TestSprite النشر التجريبي (preview) لطلب السحب ويُعلّق بالنتيجة مباشرة عليه.
الدفع (Push) إلى فرع
الأفضل لاختبار بيئة مشتركة مثل staging أو dev بعد كل عملية دمج. تصل النتائج كفحص على الـ commit.
شغّل كليهما، باستقلالية
أنشئ مُشغّل طلب سحب ومُشغّل دفع على نفس المستودع — يعملان وفق جدوليهما الخاصين، دون أي تداخل.
موجّهات إصلاح جاهزة للّصق
يتضمن كل إخفاق موجّه إصلاح مقترحًا يصف السبب الجذري المحتمل — انسخه مباشرة إلى وكيل الترميز بالذكاء الاصطناعي الخاص بك.
موثوق به من قبل الشركات حول العالم
"يقدم TestSprite إنشاء حالات اختبار غنية، وهيكلًا واضحًا، وكودًا سهل القراءة. كما يدعم تصحيح الأخطاء البسيط عبر الإنترنت مع القدرة على التوسع بسرعة عن طريق إنشاء حالات اختبار جديدة."
"تساعد أتمتة TestSprite في تقليل الكثير من العمل اليدوي. يمكن للمطورين بسهولة اكتشاف الأخطاء وحلها في وقت مبكر من عملية التطوير."
الأسئلة الشائعة
هل يستبدل هذا سير عمل GitHub Actions الحالي لدي؟
لا. يستمع TestSprite للأحداث التي ينتجها سير عملك بالفعل — نشر، أو بناء، أو فحص حالة — ويتفاعل معها. لا يُعدّل أو يستبدل خط الأنابيب لديك، ولا يُضاف أي ملف سير عمل إلى مستودعك.
ما الصلاحيات التي يحتاجها تطبيق GitHub؟
صلاحية قراءة لـ Actions، والفحوصات، والقضايا (issues)، والبيانات الوصفية؛ وصلاحية قراءة وكتابة للكود، وحالات الـ commit، وعمليات النشر، وطلبات السحب. تُستخدم صلاحية الكتابة فقط لنشر نتائج الاختبار كتعليقات على طلب السحب أو فحوصات commit — لا يدفع TestSprite commits ولا يُعدّل ملفات سير العمل.
ما مزوّدو الاستضافة المدعومون؟
أي مزوّد يُبلّغ عن عملية نشر إلى GitHub ويعرض رابطًا يمكن الوصول إليه — بما في ذلك Vercel وAWS Amplify وNetlify وخطوط الأنابيب ذاتية الاستضافة التي تُنشئ عمليات نشر على GitHub.
ماذا لو كانت روابط المعاينة لدي تستخدم نطاقًا فرعيًا عشوائيًا، لا رقم طلب السحب؟
يتوقع حقل نمط عنوان URL نمطًا يمكن التنبؤ به، باستخدام عناصر نائبة مثل {pr} و{branch} و{branch-slug} و{sha}. إذا كانت جهة الاستضافة لديك تُولّد نطاقات فرعية غير متوقعة، فقم بتهيئة رابط مستعار ثابت لبيئة المعاينة ووجّه TestSprite إليه بدلًا من ذلك.
ما الذي يظهر في النتيجة؟
عدد رئيسي للنجاح/الفشل/الحالات المحجوبة، ودرجة جودة مُحتسبة على الجزء القابل للتنفيذ من المجموعة (تُبلَّغ الحالات المحجوبة بشكل منفصل، لأنها عادة ما تشير إلى فجوة في بيئة الاختبار لا إلى تراجع في المنتج)، وتفاصيل كاملة للمتوقع مقابل الملحوظ مع لقطة شاشة لكل إخفاق، وموجّه إصلاح جاهز للنسخ لوكيل الترميز الخاص بك.
امنح كل عملية نشر اختبارًا حقيقيًا، تلقائيًا.
اربط مستودعًا مرة واحدة. يتولى TestSprite الباقي — دون ملف سير عمل، ودون تغييرات على خط الأنابيب لديك، وتعليق أو فحص على كل طلب سحب ودفع.