كيفية اختبار طلبات الحذف لاختبار واجهة برمجة التطبيقات باستخدام بلاي رايت جافا

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

في هذه المدونة، سنتناول ونتعلم حول طلبات واجهة برمجة التطبيقات من نوع DELETE وكيفية التعامل معها باستخدام Playwright Java لاختبار الأتمتة، مع تغطية النقاط التالية:

1. ما هو طلب DELETE؟
2. كيف تختبر واجهات برمجة التطبيقات من نوع DELETE باستخدام Playwright Java؟

البدء

يوصى بأن تتحقق من مدونة الدروس السابقة لتتعرف على التفاصيل المتعلقة بالمتطلبات المسبقة، والإعداد، والتكوين.

التطبيق الذي يتم اختباره

سنستخدم واجهات برمجة التطبيقات المجانية RESTful للتجارة الإلكترونية التي تقدم واجهات متعددة تتعلق بوظائف إدارة الطلبات، مما يتيح لنا إنشاء واسترجاع وتحديث وحذف الطلبات.

يمكن إعداد هذا التطبيق محليًا باستخدام Docker أو NodeJS.

ما هو طلب DELETE؟

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

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

وفيما يلي بعض القيود على طلبات DELETE:

1. البيانات المحذوفة باستخدام طلب DELETE غير قابلة للتراجع، لذا يجب التعامل معها بحذر.
2. لا تعتبر طريقة آمنة حيث يمكن أن تحذف المورد مباشرة من قاعدة البيانات، مما يسبب صراعات في النظام.
3. كما أنها ليست طريقة متكررة، مما يعني أن استدعاءها عدة مرات لنفس المورد قد يؤدي إلى حالات مختلفة. على سبيل المثال، في المرة الأولى، عند استدعاء DELETE، ستعيد رمز الحالة 204 الذي يشير إلى أنه تم حذف المورد، وإذا تم استدعاء DELETE مرة أخرى على نفس المورد، فقد تعطي 404 غير موجود حيث أن المورد المعطى قد تم حذفه بالفعل.

وفيما يلي مثال على نقطة نهاية واجهة برمجة التطبيقات DELETE من مشروع التجارة الإلكترونية القائم على REST.

DELETE /deleteOrder/{id} :  يحذف طلبًا بواسطة ID

تتطلب هذه الواجهة برمجة التطبيقات توفير order_id كـ معامل مسار لحذف الطلب المعني من النظام. لا يتطلب توفير جسم طلب في هذا الطلب API DELETE. ومع ذلك، كإجراء أمني، يتطلب توفير token كـ header لحذف الطلب.

بمجرد تنفيذ واجهة برمجة التطبيقات، تقوم بحذف الطلب المحدد من النظام وتعيد رمز الحالة 204.

في حالة عدم العثور على الطلب، أو إذا كان الرمز المميز غير صالح أو غير متوفر، ستظهر الاستجابة التالية:

كيفية اختبار واجهات برمجة التطبيقات DELETE باستخدام Playwright Java

يعد اختبار واجهات برمجة التطبيقات DELETE خطوة مهمة لضمان استقرار وموثوقية التطبيق. إن التنفيذ الصحيح لواجهات برمجة التطبيقات DELETE ضروري للتحقق من فقدان البيانات غير المقصود وعدم التناسق، حيث أن واجهات برمجة التطبيقات DELETE مسؤولة عن إزالة الموارد من النظام.

في هذه العرض للاختبار باستخدام واجهات برمجة التطبيقات DELETE باستخدام Playwright Java، سنستخدم /deleteOrder/{id} لحذف طلب موجود من النظام.

سيناريو الاختبار 1:  حذف طلب صالح

1. ابدأ خدمة التجارة الإلكترونية RESTful.
2. باستخدام طلب POST، أنشئ بعض الطلبات في النظام.
3. احذف الطلب بالمعرف order_id “1” باستخدام طلب DELETE.
4. تحقق من أن رمز الحالة 204 قد تم إرجاعه في الاستجابة.

تنفيذ الاختبار

الخطوات التالية مطلوبة لتنفيذ سيناريو الاختبار:

1. أضف طلبات جديدة باستخدام طلب POST.
2. قم بالاتصال بواجهة برمجة التطبيقات /auth لتوليد الرمز.
3. قم بالاتصال بنقطة نهاية واجهة برمجة التطبيقات /deleteOrder/ مع الرمز و order_id لحذف الطلب.
4. تحقق من أن رمز الحالة 204 تم إرجاعه في الاستجابة.

تم إنشاء طريقة اختبار جديدة، testShouldDeleteTheOrder(), في فئة الاختبار الموجودة HappyPathTests. تقوم هذه الطريقة الاختبارية بتنفيذ الخطوات الثلاث المذكورة أعلاه لاختبار واجهة برمجة التطبيقات DELETE.

@Test

    public void testShouldDeleteTheOrder() {

​

        final APIResponse authResponse = this.request.post("/auth", RequestOptions.create().setData(getCredentials()));

​

        final JSONObject authResponseObject = new JSONObject(authResponse.text());

        final String token = authResponseObject.get("token").toString();

​

        final int orderId = 1;

        final APIResponse response = this.request.delete("/deleteOrder/" + orderId, RequestOptions.create()

                .setHeader("Authorization", token));

        assertEquals(response.status(), 204);

    }

سيتم الاتصال أولاً بنقطة نهاية واجهة برمجة التطبيقات POST /auth لتوليد الرمز. يتم تخزين token المستلم في الاستجابة في متغير الرمز ليتم استخدامه لاحقًا في طلب واجهة برمجة التطبيقات DELETE.

بعد ذلك، سيتم إنشاء طلبات جديدة باستخدام طريقة testShouldCreateNewOrders()، التي تم مناقشتها بالفعل في الدروس السابقة، حيث تحدثنا عن اختبار طلبات POST باستخدام Playwright Java.

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

سنقوم بحذف الطلب برقم order_id “1” باستخدام  delete() الطريقة المقدمة من إطار عمل Playwright.

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

تنفيذ الاختبار

سنقوم بإنشاء ملف testng.xml جديد باسم testng-restfulecommerce-deleteorders.xml لتنفيذ الاختبارات بالترتيب الذي تم مناقشته في تنفيذ الاختبار.

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE suite SYSTEM "http://testng.org/testng-1.0.dtd">

<suite name="Restful ECommerce Test Suite">

    <test name="Testing Happy Path Scenarios of Creating and Updating Orders">

        <classes>

            <class name="io.github.mfaisalkhatri.api.restfulecommerce.HappyPathTests">

                <methods>

                    <include name="testShouldCreateNewOrders"/>

                    <include name="testShouldDeleteTheOrder"/>

                </methods>

            </class>

        </classes>

    </test>

</suite>

أولاً، سيتم تنفيذ طريقة الاختبار testShouldCreateNewOrders() وسيقوم بإنشاء طلبات جديدة. ثم، سيتم تنفيذ طريقة اختبار الطلب testShouldDeleteTheOrder() لتجربة واجهة برمجة التطبيقات لحذف الطلب.

تظهر لقطة الشاشة التالية لتنفيذ الاختبار باستخدام بيئة التطوير المتكاملة IntelliJ أن الاختبارات تم تنفيذها بنجاح.

الآن، دعنا نتحقق من أن الطلب تم حذفه بشكل صحيح عن طريق كتابة اختبار جديد سيستدعي نقطة النهاية لواجهة برمجة التطبيقات GET /getOrder بالطلب المحذوف order_id.

سيناريو الاختبار 2: استرداد الطلب المحذوف

1. احذف طلب صالح بـ order_id “1”.
2. باستخدام واجهة برمجة التطبيقات GET /getOrder، حاول استرداد الطلب بـ order_id “1”.
3. تحقق من أن الرمز الحالة 404 يتم إرجاعه مع الرسالة “لم يتم العثور على طلب بالمعلمات المحددة!” في الرد.

تنفيذ الاختبار

لنقم بإنشاء طريقة اختبار جديدة، testShouldNotRetrieveDeletedOrder()، في الفئة الحالية HappyPathTests.

@Test

    public void testShouldNotRetrieveDeletedOrder() {

        final int orderId = 1;

        final APIResponse response = this.request.get("/getOrder", RequestOptions.create().setQueryParam("id", orderId));

​

        assertEquals(response.status(), 404);

​

        final JSONObject jsonObject = new JSONObject(response.text());

        assertEquals(jsonObject.get("message"), "No Order found with the given parameters!");

    }

تنفيذ اختبار هذا السيناريو بسيط جدًا. سنقوم بتنفيذ واجهة برمجة التطبيقات GET /getOrder لاسترجاع الطلب المحذوف مع order_id “1”.

يتم تطبيق تأكيد بعد ذلك للتحقق من أنه يجب على واجهة برمجة التطبيقات GET أن تعيد رمز الحالة 404 في الاستجابة مع الرسالة “لم يتم العثور على طلب بالمعلمات المعطاة!”

يضمن هذا الاختبار أن واجهة برمجة التطبيقات لحذف الطلب عملت بشكل جيد وأن الطلب تم حذفه من النظام.

تنفيذ الاختبار

لنقم بتحديث ملف testng.xml ونضيف هذا السيناريو الاختباري في النهاية بعد اختبار الحذف.

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE suite SYSTEM "http://testng.org/testng-1.0.dtd">

<suite name="Restful ECommerce Test Suite">

    <test name="Testing Happy Path Scenarios of Creating and Updating Orders">

        <classes>

            <class name="io.github.mfaisalkhatri.api.restfulecommerce.HappyPathTests">

                <methods>

                    <include name="testShouldCreateNewOrders"/>

                    <include name="testShouldDeleteTheOrder"/>

                    <include name="testShouldNotRetrieveDeletedOrder"/>

                </methods>

            </class>

        </classes>

    </test>

</suite>

الآن، يجب أن يتم تشغيل الاختبارات الثلاثة بالتسلسل. الأول سيقوم بإنشاء الطلبات؛ والثاني سيحذف الطلب مع order_id “1”؛ وآخر اختبار سيقوم بالاتصال بواجهة برمجة التطبيقات GET لاسترجاع الطلب مع order_id “1” مع إعادة رمز الحالة 404.

تُظهر لقطة الشاشة أعلاه أن جميع الاختبارات الثلاثة تم تنفيذها بنجاح، وأن واجهة برمجة التطبيقات DELETE عملت بشكل جيد كما هو متوقع.

ملخص

تسمح طلبات واجهة برمجة التطبيقات DELETE بحذف المورد من النظام. نظرًا لأن الحذف هو وظيفة CRUD مهمة، فإنه من الضروري اختباره والتحقق من أن النظام يعمل كما هو متوقع. ومع ذلك، يجب ملاحظة أن DELETE هو عملية غير قابلة للتراجع، لذا يجب استخدامه دائمًا بحذر.

استنادًا إلى تجربتي، من الجيد تنفيذ طلب GET بعد تنفيذ طلب DELETE للتحقق من أنه تم حذف المورد المحدد من النظام بنجاح.

تمنيات بالتوفيق في الاختبار!