בדוק REST API עם Java

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

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

המטרה העיקרית היא לספק מבוא לבדיקת הנכונות הבסיסית של ה- API - ואנחנו נשתמש בגרסה האחרונה של ה- GitHub REST API לדוגמאות.

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

בעת בדיקת משאב REST, בדרך כלל יש כמה אחריות אורתוגונלית שהבדיקות צריכות להתמקד בהן:

  • ה- HTTP קוד תגובה
  • HTTP אחר כותרות בתגובה
  • ה מטען (JSON, XML)

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

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

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

@Test ציבורי בטל שניתןUserDoesNotExists_whenUserInfoIsRetrieved_then404IsReceived () זורק ClientProtocolException, IOException {// ניתן שם מחרוזת = RandomStringUtils.randomAlphabetic (8); HttpUriRequest בקשה = HttpGet חדש ("//api.github.com/users/" + שם); // כאשר HttpResponse httpResponse = HttpClientBuilder.create (). Build (). Execute (בקשה); // ואז assertThat (httpResponse.getStatusLine (). GetStatusCode (), equalTo (HttpStatus.SC_NOT_FOUND)); }

זהו מבחן פשוט למדי - זה מאמת שדרך מאושרת בסיסית עובדת, בלי להוסיף יותר מדי מורכבות לחבילת הבדיקה.

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

3. בדיקת סוג המדיה

@Test הציבור בטל givenRequestWithNoAcceptHeader_whenRequestIsExecuted_thenDefaultResponseContentTypeIsJson () זורק ClientProtocolException, IOException {// נתון מחרוזת jsonMimeType = "יישום / json"; HttpUriRequest בקשה = HttpGet חדש ("//api.github.com/users/eugenp"); // כאשר תגובה HttpResponse = HttpClientBuilder.create (). Build (). Execute (בקשה); // ואז מחרוזת mimeType = ContentType.getOrDefault (response.getEntity ()). GetMimeType (); assertEquals (jsonMimeType, mimeType); }

זה מבטיח שהתגובה אכן מכילה נתוני JSON.

כפי ששמתם לב, אנו עוקבים אחר התקדמות הגיונית של מבחנים - ראשית קוד סטטוס התגובה (כדי להבטיח שהבקשה הייתה בסדר), ואז סוג המדיה של התגובה, ורק במבחן הבא נבחן את המטען האמיתי של JSON.

4. בדיקת מטען ה- JSON

@Test ציבורי בטל שניתןUserExists_whenUserInformationIsRetrieved_thenRetrievedResourceIsCorrect () זורק ClientProtocolException, IOException {// בהינתן HttpUriRequest בקשה = HttpGet חדש ("//api.github.com/users/eugenp"); // כאשר תגובה HttpResponse = HttpClientBuilder.create (). Build (). Execute (בקשה); // ואז GitHubUser resource = RetrieveUtil.retrieveResourceFromResponse (תגובה, GitHubUser.class); assertThat ("eugenp", Matchers.is (resource.getLogin ())); }

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

5. כלי עזר לבדיקה

אנו נשתמש בג'קסון 2 כדי לפרק את מחרוזת JSON הגולמית לישות Java בטוחה לסוגיה:

מחלקה ציבורית GitHubUser {פרטי כניסה למחרוזת; // סטרים וקובעים סטנדרטיים}

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

ציבורי סטטי ציבורי retrieveResourceFromResponse (תגובה HttpResponse, Class class) זורק IOException {String jsonFromResponse = EntityUtils.toString (response.getEntity ()); מיפוי ObjectMapper = ObjectMapper חדש () .configure (DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, false); mapper return.readValue (jsonFromResponse, clazz); }

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

6. תלות

כלי השירות והבדיקות משתמשים בספריות הבאות, שכולן זמינות במרכז Maven:

  • HttpClient
  • ג'קסון 2
  • Hamcrest (אופציונלי)

7. מסקנה

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

לדוגמה, הדברים הבאים אינם מכוסים: גילוי ה- API, צריכת ייצוגים שונים עבור אותו משאב וכו '.

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


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