سيلينيوم لاختبار واجهات برمجة التطبيقات: هل يمكنك وهل يجب عليك؟

سيلينيوم هو إطار عمل لأتمتة المتصفحات. يقوم بتشغيل متصفحات Chrome و Firefox وغيرها بالطريقة التي يقوم بها الإنسان: النقر على الأزرار، ملء النماذج، قراءة الصفحة المعروضة. إنه الأداة القياسية لاختبار الواجهة الأمامية الشامل، وهو ممتاز في هذه المهمة.

ما زال الناس يتساءلون عما إذا كان سيلينيوم يمكنه اختبار واجهات برمجة التطبيقات (APIs). الإجابة الصريحة هي أنه يمكنك جعله يصدر طلبات HTTP، ولكنه الأداة الخاطئة لهذه المهمة. يشرح هذا الدليل بالتحديد سبب ذلك، ويظهر كيف يبدو اختبار API عبر سيلينيوم في الواقع، ويوجهك إلى الأدوات المصممة لهذه المهمة. الهدف هو إنقاذك من إعداد قد يحبطك لاحقًا.

لماذا لا يتوافق سيلينيوم مع اختبار واجهة برمجة التطبيقات (API)

يرسل اختبار API طلب HTTP مباشرة إلى الخادم ويتحقق من الاستجابة: رمز الحالة، الرؤوس، الجسم، التوقيت. لا توجد واجهة مستخدم متضمنة. يجب أن يكون الاختبار سريعًا ومعزولًا ورخيصًا لتشغيله آلاف المرات.

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

هناك عدم تطابق أعمق أيضًا. واجهة برمجة تطبيقات سيلينيوم بأكملها تدور حول العناصر الموجودة على الصفحة: ابحث عن هذا الزر، اقرأ هذا النص، انتظر هذا العنصر. استجابة HTTP ليست صفحة. ليس لها DOM. لذا، فإن سيلينيوم لا يمنحك شيئًا مفيدًا لفحص جسم JSON، أو التأكيد على رأس، أو التحقق من رمز الحالة. ينتهي بك الأمر بالعمل حول الأداة بدلاً من العمل بها.

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

ماذا يعني "اختبار واجهة برمجة التطبيقات باستخدام سيلينيوم" في الواقع

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

الخيار الأول: استخدام منفذ JavaScript الخاص بسيلينيوم. يمكن لسيلينيوم تشغيل أي JavaScript عشوائي في المتصفح الذي يتحكم فيه. تحتوي المتصفحات الحديثة على واجهة برمجة تطبيقات fetch، لذا يمكنك أن تطلب من المتصفح إجراء طلب وتسليم النتيجة مرة أخرى إلى كود الاختبار الخاص بك:

JavascriptExecutor js = (JavascriptExecutor) driver;
Object status = js.executeAsyncScript(
    "const callback = arguments[arguments.length - 1];" +
    "fetch('https://jsonplaceholder.typicode.com/users/1')" +
    "  .then(r => callback(r.status))" +
    "  .catch(e => callback('error: ' + e));"
);
System.out.println("Status code: " + status);

هذا يعمل. ويعني أيضًا أنك قمت بتشغيل متصفح، وWebDriver، وجسر JavaScript فقط لإجراء استدعاء HTTP واحد يمكن لعميل HTTP عادي القيام به مباشرة. كما أنك ترث قيود المتصفح مثل CORS، والتي لا يضطر اختبار API من خادم إلى خادم إلى التفكير فيها أبدًا.

الخيار الثاني: تجاهل سيلينيوم واستخدام مكتبة HTTP حقيقية بجانبه. في مشروع Java، يعني هذا إقران سيلينيوم بـ REST Assured لأجزاء API:

import static io.restassured.RestAssured.given;
import static org.hamcrest.Matchers.equalTo;

given()
    .when()
    .get("https://jsonplaceholder.typicode.com/users/1")
    .then()
    .statusCode(200)
    .body("email", equalTo("Sincere@april.biz"));

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

متى يكون مزجها معقولًا

هناك حالة واحدة مشروعة لعمل HTTP داخل مجموعة سيلينيوم، ومن الجدير توضيحها. غالبًا ما تحتاج اختبارات واجهة المستخدم (UI) الخاصة بسيلينيوم إلى إعداد أو إنهاء يكون أسرع عبر واجهة برمجة التطبيقات (API) منه عبر المتصفح.

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

هذه ممارسة سليمة. استدعاء API هو وسيلة لتحقيق غاية، وليس هو الشيء الذي يتم اختباره. يجب أن يظل استدعاء API يمر عبر عميل HTTP حقيقي، وليس عبر منفذ JavaScript. لذلك حتى في هذه الحالة، لا يقوم سيلينيوم باختبار API. إنه يقوم باختبار واجهة المستخدم، ويتولى عميل HTTP المناسب جانب API.

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

استخدم أداة مصممة لاختبار واجهات برمجة التطبيقات (API)

إذا كان هدفك هو اختبار واجهات برمجة التطبيقات (APIs)، فاستخدم شيئًا مصممًا لذلك. الفرق ليس بسيطًا. تمنحك أداة اختبار API حقيقية بناء الطلبات، وإدارة البيئة، وتأكيدات على الحالة، والرؤوس، والجسم، وسلسلة الطلبات، وعمليات التشغيل المعتمدة على البيانات، وتكامل CI، دون تشغيل متصفح.

خياراتك تقع في عدة مجموعات:

إذا كنت تفضل الكود، فإن مكتبة HTTP مثل REST Assured في Java، أو requests في Python، أو supertest في Node هي الخيار الصحيح. تقوم هذه المكتبات بإجراء طلب وتسليم الاستجابة إليك مباشرةً، مع أدوات مساعدة للتأكيد مصممة لرموز الحالة وأجسام JSON. لا يوجد متصفح، ولا WebDriver، ولا عرض، لذلك تعمل مجموعة الاختبارات الكاملة بسرعة وتفشل فقط عندما تتغير واجهة برمجة التطبيقات نفسها.

إذا كنت ترغب في مساحة عمل مرئية، فإن Apidog هي منصة API شاملة تغطي تصميم واجهة برمجة التطبيقات، وتصحيح أخطاء الطلبات، ومحاكاة نقاط النهاية، وبناء سيناريوهات الاختبار الآلي، وتوليد التوثيق، كل ذلك في مشروع واحد. يمكنك بناء التأكيدات بصريًا أو باستخدام النصوص البرمجية، وربط الطلبات في تدفقات متعددة الخطوات، وتشغيل تكرارات تعتمد على البيانات، وتنفيذ كل شيء في CI. كما أنه يستورد ملفات OpenAPI و Postman، لذلك يمكن إدخال واجهة برمجة تطبيقات موجودة بسرعة. لا شيء من ذلك يتضمن متصفحًا، لأنه لا يجب أن يتضمن. يمكنك تنزيل Apidog لتجربته على واجهة برمجة تطبيقات حقيقية.

بالنسبة للفرق التي ترغب في إطار عمل يعتمد على الكود أولاً، تغطي الأدلة حول إطار عمل Robot لأتمتة API وبناء إطار عمل لأتمتة اختبار API مقاربات، بخلاف سيلينيوم، مناسبة بالفعل لاختبار HTTP.

الخلاصة الصادقة

سيلينيوم برنامج ممتاز لما صمم له، وهو أتمتة المتصفحات. اختبار واجهة برمجة التطبيقات (API) ليس كذلك. يمكنك من الناحية الفنية دفع HTTP عبر منفذ JavaScript الخاص بسيلينيوم، ويمكنك الاحتفاظ بمكتبة HTTP في نفس المشروع الذي يحتوي على سيلينيوم، ولكن في كلتا الحالتين، لا يضيف سيلينيوم قيمة لاختبار واجهة برمجة التطبيقات نفسه.

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

الأسئلة الشائعة

هل يمكن لسيلينيوم اختبار واجهات برمجة تطبيقات REST على الإطلاق؟

يمكنه إصدار طلبات HTTP عبر منفذ JavaScript الخاص بالمتصفح، لذلك بالمعنى التقني الضيق، نعم. لكن سيلينيوم لا يحتوي على ميزات لفحص الاستجابات، أو التأكيد على JSON، أو التحقق من الرؤوس، ويتحمل العبء الكامل للمتصفح. إنه ليس أداة لاختبار واجهات برمجة تطبيقات REST، واستخدامه كأداة يؤدي إلى اختبارات بطيئة وهشة.

لماذا تعرض بعض الدروس التعليمية سيلينيوم مع REST Assured؟

لأن اختبار API في تلك الدروس التعليمية يتم بالكامل بواسطة REST Assured، وهي مكتبة اختبار HTTP حقيقية. سيلينيوم موجود فقط في نفس المشروع لاختبارات واجهة المستخدم غير ذات الصلة. الاقتران جيد، لكنه لا يعني أن سيلينيوم يختبر API. REST Assured هو من يقوم بذلك.

هل من المقبول أبدًا إجراء استدعاءات API في اختبار سيلينيوم؟

نعم، للإعداد والإنهاء. إنشاء بيانات الاختبار عبر واجهة برمجة التطبيقات (API) أسرع وأكثر موثوقية من النقر عبر واجهة المستخدم لإنتاجها. يدعم استدعاء واجهة برمجة التطبيقات اختبار واجهة المستخدم بدلاً من أن يكون هو الشيء قيد الاختبار، ويجب أن يظل يستخدم عميل HTTP مناسبًا، وليس منفذ JavaScript الخاص بسيلينيوم.

ماذا يجب أن أستخدم بدلاً من سيلينيوم لاختبار واجهة برمجة التطبيقات (API)؟

للاختبار الذي يعتمد على الكود أولاً، مكتبة HTTP مثل REST Assured، أو requests في بايثون، أو supertest لـ Node. لمساحة عمل مرئية، منصة API مخصصة مثل Apidog، أو عملاء مثل Postman و Insomnia و Talend API Tester. كل هذه الأدوات مصممة لـ HTTP وتتجنب العبء الزائد للمتصفح الذي يفرضه سيلينيوم.

هل استخدام سيلينيوم لاختبارات واجهة برمجة التطبيقات يبطئ مسار التكامل المستمر (CI) الخاص بي؟

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