اختبار API باستخدام Selenium: ما الذي يناسبه وما لا يناسبه

لماذا يُطرح اختبار API باستخدام Selenium من الأساس

ثلاثة أسباب، واحد منها فقط وجيه.

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

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

• التهيئة والتنظيف. إنشاء بيانات التهيئة عبر API لأن إنشاءها عبر الواجهة بطيء. تصرّف معقول، لكنه تجهيز لا اختبار.

ما الذي يكلّفه ذلك

التقسيم الذي ينجح

احتفظ بـ Selenium لما لا يجيب عنه سوى المتصفح: هل يعمل المسار الظاهر للمستخدم. وغطِّ API على مستواه الخاص، حيث يكون الفحص طلبًا لا تحميلًا لصفحة. ولا تستخدم API من داخل مجموعة Selenium إلا في التهيئة والتنظيف، حيث تكون السرعة هي المقصد ولا ينطوي الأمر على أي توكيد.

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

ما الذي يجب أن تعالجه طبقة API المستقلة

أربعة أمور تحدّد ما إذا كانت مجموعة اختبارات API ستصمد في عامها الأول، أيًّا كانت الأداة التي تستخدمها: جلسات تنتهي صلاحيتها، وقيم لا توجد إلا في وقت التشغيل، واستدعاءات يعتمد بعضها على بعض، وسجلات لا ينظّفها أحد. تسمّي TestSprite هذه الأمور Auto-Authentication وDynamic Variables وDependency Chains وAuto-Cleanup، ويتناول توثيق اختبار API آليات عملها.

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

حالة التهيئة، منفَّذة كما ينبغي

استخدام API لإنشاء بيانات التهيئة لاختبار متصفح هو الموضع الوحيد الذي ينتمي فيه الاثنان معًا حقًا، ويستحق أن يُنفَّذ عن قصد لا بالمصادفة.

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

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

تشغيل الاثنين معًا

لا تحتاج أي من المجموعتين إلى معرفة الأخرى. يعمل Selenium في مهمة التكامل المستمر لديك كما هو الحال اليوم، وتعمل تغطية API إلى جانبه.

إذا كان خط الإنتاج تابعًا لفريق آخر، فإن GitHub App هو طريق المقاومة الأقل: فهو مجرد webhook، ولا يغيّر شيئًا في مستودعك، ويُطلَق عندما يُبلّغ بناؤك بأن الإصدار الجديد أصبح مباشرًا. وإذا كنت تريد أن يظهر الفحص داخل المستودع بدلًا من ذلك، فإن خطوة GitHub Actions تؤدّي هذا الغرض. راجع مستودع CLI.

ما الذي تغطّيه TestSprite على مستوى API

تتولّى TestSprite طبقة API المستقلة حتى لا تضطر إلى إلحاقها بمجموعة اختبارات متصفح. تُعدِّد API Discovery ما تكشفه الخدمة قيد التشغيل، وتقترح Plan Generation حالات اختبار تشمل الفئات الوظيفية والمخطَّط والصلاحيات ومعالجة الأخطاء والحالات الحدّية، ثم تصقلها أنت بلغة عادية.

وتأتي مشكلات الحالة الأربع كجزء من المنتج لا كبنية تحتية تبنيها بنفسك: يُبقي Auto-Authentication الجلسات حيّة، وتنقل Dynamic Variables القيم بين الاستدعاءات، وتستنتج Dependency Chains ترتيب التنفيذ، ويزيل Auto-Cleanup ما أنشأته الجولة. هذه هي الأمور التي تجعل إبقاء مجموعة اختبارات API حيّة أمرًا صعبًا، وحلّها على مستوى API أسهل بكثير من حلّها داخل مشغّل متصفح.

تبقى مجموعة Selenium لديك في مكانها، تغطّي ما لا يجيب عنه سوى المتصفح. وتعمل الاثنتان من خط الإنتاج نفسه.