איך לבדוק בקשות DELETE לבדיקת API עם Playwright Java

בדיקות API זכו להמון תנופה בימים אלו. מכיוון שאין מע involvement UI, הרבה יותר קל ומהיר לבדוק. זו הסיבה לכך שבדיקות API נחשבות לבחירה הראשונה לביצוע בדיקות קצה לקצה של המערכת. שילוב בדיקות API האוטומטיות עם צינורות CI/CD מאפשר לצוותים לקבל משוב מהיר יותר על הבניות.

בבלוג הזה, נדון ונלמד על בקשות DELETE API ואיך לטפל בהן באמצעות Playwright Java עבור בדיקות אוטומטיות, עם הכיסוי של הנושאים הבאים:

1. מהי בקשת DELETE?
2. איך אתה בודק APIs מסוג DELETE באמצעות Playwright Java?

התחלה

מומלץ שתבדוק את הבלוג ההדרכה הקודם כדי ללמוד על הפרטים הקשורים לדרישות מוקדמות, התקנה, והגדרה.

יישום תחת בדיקה

נשתמש ב-API של מסחר אלקטרוני חינמיים לשימוש המציעים מספר APIs הקשורים לפונקציית ניהול הזמנות, ומאפשרים לנו ליצור, לאחזר, לעדכן ולמחוק הזמנות.

יישום זה ניתן להקים מקומית באמצעות Docker או NodeJS.

מהי בקשת DELETE?

בקשת API מסוג DELETE מוחקת את המשאב המוגדר מהשרת. בדרך כלל, אין גוף תגובה בבקשות DELETE.

המשאב מוגדר על ידי URI, והשרת מוחק אותו לצמיתות. בקשות DELETE אינן נחשבות לבטוחות ולא אידמפטות, מכיוון שהן עשויות לגרום להשפעות צד על השרת, כמו הסרת נתונים ממסד נתונים.

הנה כמה מהמגבלות של בקשות DELETE:

1. הנתונים שנמחקים באמצעות בקשת DELETE אינם ניתנים להחזרה, ולכן יש לטפל בהם בזהירות.
2. זה לא נחשב לשיטה בטוחה מכיוון שהיא יכולה למחוק ישירות את המשאב ממסד הנתונים, مما导致 קונפליקטים במערכת.
3. זו לא שיטה אידמפטית, כלומר קריאה לה מספר פעמים עבור אותו משאב עשויה להניב מצבים שונים. לדוגמה, במופע הראשון, כאשר מתקבלת קריאת DELETE, היא תחזיר קוד מצב 204 המצהיר שהמשאב נמחק, ואם קריאת DELETE תתבצע שוב על אותו משאב, היא עשויה להחזיר 404 NOT FOUND מכיוון שהמשאב הנתון כבר נמחק.

הנה דוגמה לנקודת קצה של API מסוג DELETE מפרויקט המסחר האלקטרוני RESTful.

DELETE /deleteOrder/{id} :  מוחק הזמנה לפי מזהה

API זה דורש שהorder_id יסופק כפרמטר מסלול על מנת למחוק את ההזמנה המתאימה מהמערכת. אין צורך לספק גוף בקשה בבקשת API מסוג DELETE זו. עם זאת, כצעד אבטחה, יש לספק את הtoken ככותרת כדי למחוק את ההזמנה.

פעם שה- API מופעל, הוא מוחק את ההזמנה המסוימת מהמערכת ומחזיר קוד מצב 204.

במקרה בו ההזמנה לא נמצאת, או הטוקן אינו חוקי או לא סופק, יוצג התשובה הבאה בהתאם:

כיצד לבדוק את ה- API של DELETE באמצעות Playwright Java

בדיקת ה- API של DELETE היא שלב חשוב לוודא את יציבות ואמינות היישום. היישום התקין של ה- API של DELETE הוא חיוני כדי לבדוק עבור אובדן נתונים לא מתוכנן וחוסרי עקביות, מאחר שה- API של DELETE אחראי על הסרת המשאבים מהמערכת.

בהדגמה זו של בדיקת ה- API של DELETE באמצעות Playwright Java, נשתמש ב- /deleteOrder/{id} עבור מחיקת הזמנה קיימת מהמערכת.

תרחיש בדיקה 1:  מחיקת הזמנה תקפה

1. התחל את שירות המסחר האלקטרוני המתבצע באמצעות RESTful.
2. באמצעות בקשת POST, צור מספר הזמנות במערכת.
3. מחק את ההזמנה עם order_id "1" באמצעות בקשת DELETE.
4. בדוק כי קוד מצב 204 מוחזר בתגובה.

יישום הבדיקה

השלבים הבאים נדרשים לביצוע התרחיש הבדיקה:

1. הוסף הזמנות חדשות באמצעות בקשת POST.
2. לחץ על ה- API /auth כדי ליצור טוקן.
3. הקש על נקודת הקצה API /deleteOrder/ עם הטוקן וה- order_id כדי למחוק את ההזמנה.
4. בדוק שקוד המצב 204  נמצא בתשובה.

שיטת בדיקה חדשה,  testShouldDeleteTheOrder(), נוצרת במחלקת הבדיקות הקיימת HappyPathTests. שיטת הבדיקה הזו מיישמת את השלושה צעדים לבדיקת ה- API 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 שמתקבל בתגובה נשמר במשתנה הטוקן כדי לשמש בקשת ה- API 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() תתבצע כדי לבדוק את API למחיקת הזמנה.

התמונה הבאה מראה את ביצוע הבדיקה באמצעות IntelliJ IDE והראה שהבדיקות בוצעו בהצלחה.

כעת, נוודא שההזמנה נמחקה בהצלחה על ידי כתיבת בדיקה חדשה שתקרא ל-GET /getOrder עם ה-order_id שנמחק.

תרחיש בדיקה 2:  לרטוט את ההזמנה שנמחקה

1. מחק הזמנה תקפה עם order_id "1."
2. באמצעות ה-GET /getOrder API, תנסה לאחזר את ההזמנה עם 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 API כדי לחפש את ההזמנה שנמחקה עם order_id “1.”

לאחר מכן מוחלת טענה כדי לאמת שה-GET API אמור להחזיר את קוד הסטטוס 404 בתגובה עם ההודעה “לא נמצאה הזמנה עם הפרמטרים הנתונים!”

מבחן זה מבטיח שה-API למחיקת הזמנה פעל בצורה תקינה וההזמנה נמחקה מהמערכת.

ביצוע מבחן

בואו נעדכן את הקובץ 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 API כדי לחפש את ההזמנה עם order_id “1” ולהחזיר קוד סטטוס 404.

התמונה למעלה מראה שכל שלושת המבחנים בוצעו בהצלחה, וה-DELETE API פעל כפי שצפינו.

סיכום

בקשות DELETE API מאפשרות את מחיקת המשאב מהמערכת. מכיוון שהמחיקה היא פונקציה חשובה ב-CRUD, חשוב לבדוק אותה ולאמת שהמערכת פועלת כפי שצפוי. עם זאת, יש לציין כי DELETE הוא תהליך בלתי הפיך, ולכן יש להשתמש בו תמיד בזהירות.

בהתאם לניסיוני, זו גישה טובה לשלוח בקשת GET לאחר ביצוע בקשת DELETE כדי לבדוק שהמשאב שצוין נמחק מהמערכת בהצלחה.

בהצלחה בבדיקות!