Cypress وTestSprite: أين يناسب كل منهما

الخلاصة أولًا

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

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

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

المقايضة الصريحة هي الطاقة مقابل التحكّم. يمنحك Cypress تحكّمًا كاملًا ويطلب في المقابل التأليف والصيانة. ويمنحك الوكيل اتساعًا دون تأليف، ويطلب منك أن تقبل أنك لم تكتب كل خطوة بنفسك.

جنبًا إلى جنب

أين يكون Cypress هو الجواب الأفضل فعلًا

هناك حالات يكون فيها اللجوء إلى وكيل غريزة خاطئة، ويستحق الأمر تسميتها.

• الاختبارات على مستوى المكوّنات. تركيب مكوّن بمعزل عن غيره والتحقق من سلوكه هو مجال Cypress. أما وكيل يقود متصفحًا فهو على ارتفاع خاطئ لهذه المهمة.

• المسارات الحتمية الحسّاسة أمنيًا. حين يكون التسلسل الدقيق مهمًّا ولا يجوز أن ينحرف أبدًا، فإن اختبارًا دُوِّنت كل خطوة فيه وخضعت للمراجعة هو الأداة الصحيحة.

• الاختبارات بوصفها مواصفة قابلة للتنفيذ. تستخدم بعض الفرق مجموعة الاختبارات بوصفها البيان المرجعي لكيفية عمل الميزة. وهذا المستند ينبغي أن يُؤلَّف لا أن يُولَّد.

• لديك بالفعل مجموعة اختبارات سليمة. مجموعة اختبارات Cypress يثق بها الناس ويصونونها هي أصل ذو قيمة، واستبدالها بالكامل لتوحيد الأدوات نادرًا ما يكون مقايضة جيدة.

أين يبلغ نموذج إطار العمل حدّه

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

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

تشغيل الاثنين دون ازدواج في العمل

التقسيم الذي ينجح عمليًا يقوم على من قرّر أن هذا الاختبار ينبغي أن يوجد.

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

إذا كنت تُجري تقييمًا، فاختبر هذا

أيًّا كان ما تقارنه، اكسر شيئًا عن عمد وراقب ما تُبلغ عنه كل أداة. أدخِل انحدارًا حقيقيًا، مثل زر حفظ لم يعد يحفظ البيانات، ثم تحقّق من ثلاثة أمور: هل يُخفق الاختبار، وهل يسمّي الإخفاق الانحراف الفعلي، وهل يستطيع الشخص أو الوكيل الذي سيصلحه أن يبدأ العمل من ذلك المخرَج دون إعادة استنتاج القصة من جديد. والأداة التي تُبلغ عن نجاح في تشغيل لم يبلغ أصلًا مرحلة التحقّقات تكون قد أخفقت في الاختبار الوحيد المهم.

ما الذي يضيفه TestSprite إلى جانب Cypress

الشيء الذي لا يستطيع Cypress منحك إياه هو تغطية لا تكلّفك وقت تأليف، وهذا هو دور TestSprite. فالحالات تُولَّد من مصادرك ومن التطبيق قيد التشغيل، ثم تُصقل بلغة بسيطة، فيتوقف الاتساع عن كونه دالة لعدد المهندسين الذين يمكنك تفريغهم.

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

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