בדיקת REST API עם קראטה

1. סקירה כללית

במאמר זה נציג את קראטה, מסגרת בדיקות להתפתחות מונעת התנהגות (BDD) עבור Java.

2. קראטה ו- BDD

קראטה היאבנוי על גבי מלפפון, מסגרת בדיקת BDD נוספת, וחולקת כמה מאותם מושגים. אחד מאלה הוא השימוש בקובץ גרקין, המתאר את התכונה שנבדקה. עם זאת, בניגוד למלפפון, המבחנים אינם כתובים בג'אווה ומתוארים במלואם בקובץ גרקין.

קובץ גרקין נשמר עם הכיתוב “תכונה ” סיומת. זה מתחיל עם תכונה מילת מפתח, ואחריה שם התכונה באותה שורה. הוא מכיל גם תרחישי בדיקה שונים, שכל אחד מהם מתחיל במילת המפתח תַרחִישׁ ומורכב משלבים מרובים עם מילות המפתח נָתוּן, מתי, לאחר מכן, וגם, ו אבל.

מידע נוסף על מלפפון ומבנה הגורקין ניתן למצוא כאן.

3. תלות Maven

כדי להשתמש בקראטה בפרויקט Maven, עלינו להוסיף את ה- קראטה-אפאצ'י תלות ב- pom.xml:

 com.intuit.karate קראטה-אפאצ'י 0.6.0 

נצטרך גם את קראטה-ג'וניט 4 תלות כדי להקל על בדיקות JUnit:

 com.intuit.karate קראטה-junit4 0.6.0 

4. יצירת בדיקות

נתחיל בכתיבת מבחנים למספר תרחישים נפוצים בגורקין תכונה קוֹבֶץ.

4.1. בדיקת קוד הסטטוס

בואו נכתוב תרחיש שבודק נקודת סיום של GET ובודק אם הוא מחזיר a 200 (אישור) קוד מצב HTTP:

תרחיש: בדיקת נקודת סיום תקפה של GET בהינתן url '// localhost: 8097 / user / get' מתי השיטה GET ואז מעמד 200

זה עובד ללא ספק עם כל קודי הסטטוס האפשריים של HTTP.

4.2. בדיקת התגובה

בואו נכתוב תרחיש נוסף שבודק שנקודת הקצה של REST מחזירה תגובה ספציפית:

תרחיש: בדיקת התגובה המדויקת של נקודת סיום של GET בהינתן url '// localhost: 8097 / user / get' מתי השיטה GET ואז סטטוס 200 והתאם $ == {id: "1234", שם: "John Smith"}

ה התאמה הפעולה משמשת לאימות איפה '$' מייצג את התגובה. אז התרחיש שלעיל בודק שהתגובה תואמת בדיוק את '{id: ”1234 ″, name:” John Smith ”} '.

אנו יכולים גם לבדוק באופן ספציפי את הערך של ה- תְעוּדַת זֶהוּת שדה:

והתאם $ .id == "1234"

ה התאמה ניתן להשתמש בפעולה גם כדי לבדוק אם התגובה מכילה שדות מסוימים. זה מועיל כאשר רק שדות מסוימים צריכים להיבדק או כשלא כל שדות התגובה ידועים:

תרחיש: בדיקה שתגובת GET מכילה שדה ספציפי נתון url '// localhost: 8097 / user / get' מתי שיטה GET ואז סטטוס 200 והתאמה $ מכילה {id: "1234"}

4.3. אימות ערכי תגובה עם סמנים

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

לדוגמא, אנו יכולים להשתמש בסמן כדי לציין אם אנו מצפים ל- ריק ערך או לא:

  • #ריק
  • #לא ריק

לחלופין נוכל להשתמש בסמן כדי להתאים סוג מסוים של ערך בשדה:

  • #boolean
  • #מספר
  • #חוּט

סמנים אחרים זמינים כאשר אנו מצפים ששדה יכיל אובייקט או מערך JSON:

  • #מַעֲרָך
  • #לְהִתְנַגֵד

ויש סמנים להתאמה בפורמט מסוים או בביטוי רגיל וכזה שמעריך ביטוי בוליאני:

  • #uuid - הערך תואם לפורמט UUID
  • #regex STR - ערך תואם את הביטוי הרגולרי STR
  • #? EXPR - טוען כי הביטוי JavaScript EXPR מעריך ל נָכוֹן

לבסוף, אם איננו רוצים שום סוג של בדיקה בשדה, אנו יכולים להשתמש ב- #להתעלם סַמָן.

בואו נכתוב מחדש את התרחיש לעיל כדי לבדוק שה- תְעוּדַת זֶהוּת שדה אינו ריק:

תרחיש: בדוק GET בקש תגובה מדויקת נתון url '// localhost: 8097 / user / get' מתי השיטה GET ואז סטטוס 200 והתאם $ == {id: "# notnull", שם: "John Smith"}

4.4. בדיקת נקודת סיום של POST עם גוף מבקש

בואו נסתכל על תרחיש סופי שבודק נקודת סיום של POST ולוקח גוף בקשה:

תרחיש: בדיקת נקודת סיום של POST עם גוף בקשה נתון url '// localhost: 8097 / user / create' and request {id: '1234', name: 'John Smith'} מתי שיטה POST ואז הסטטוס 200 והתאמה $ מכילה {id :"#לא ריק"}

5. מבחני ריצה

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

נשתמש ב- @CucumberOptions ביאור כדי לציין את המיקום המדויק של תכונה קבצים:

@RunWith (Karate.class) @CucumberOptions (features = "classpath: karate") בכיתה ציבורית KarateUnitTest {// ...}

כדי להדגים את REST API, נשתמש בשרת WireMock.

לדוגמא זו, אנחנו לועגים לכל נקודות הקצה שנבדקות בשיטה המאושרת באמצעות @לפני השיעור. אנו סוגרים את שרת WireMock בשיטה שעליה הועלה הערה @אחרי השיעור:

WireMockServer סטטי פרטי wireMockServer = WireMockServer חדש (WireMockConfiguration.options (). יציאה (8097)); @BeforeClass setUp () ריק סטטי ציבורי זורק חריג {wireMockServer.start (); configureFor ("localhost", 8097); stubFor (get (urlEqualTo ("/ user / get")) .willReturn (aResponse () .withStatus (200) .withHeader ("Type Content", "application / json") .withBody ("{\" id \ " : \ "1234 \", שם: \ "ג'ון סמית \"} "))); stubFor (post (urlEqualTo ("/ user / create")) .withHeader ("type content", equalTo ("application / json")) .withRequestBody (המכיל ("id")) .willReturn (aResponse () .withStatus (200) .withHeader ("סוג תוכן", "application / json") .withBody ("{\" id \ ": \" 1234 \ ", שם: \" ג'ון סמית \ "}"))); } @ AfterClass חלל סטטי ציבורי tearDown () זורק חריג {wireMockServer.stop (); }

כשאנחנו מנהלים את KarateUnitTest בכיתה, נקודות הקצה של REST נוצרות על ידי שרת WireMock וכל התרחישים בקובץ התכונות שצוין מופעלים.

6. מסקנה

במדריך זה בדקנו כיצד לבדוק ממשקי API של REST באמצעות מסגרת הבדיקה לקראטה.

קוד המקור השלם וכל קטעי הקוד עבור מאמר זה ניתן למצוא באתר GitHub.


$config[zx-auto] not found$config[zx-overlay] not found