חקר מסגרת המבחן בג'רזי

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

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

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

2. הגדרת יישום

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

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

בחלק הבא נראה אילו תלות עלינו להוסיף ליישום שלנו כדי להשתמש במסגרת.

2.1. תלות Maven

קודם כל, בואו נוסיף את תלות הליבה של מסגרת המבחן בג'רזי pom.xml:

 org.glassfish.jersey.test-framework jersey-test-framework-core 2.27 test 

כמו תמיד, אנו יכולים להשיג את הגרסה האחרונה ממייבן סנטרל.

כמעט כל בדיקות ג'רזי משתמשות במפעל מיכלי הבדיקה Defacto Grizzly, אותו נצטרך להוסיף גם:

 org.glassfish.jersey.test-framework.providers jersey-test-framework-provider-grizzly2 2.27 test 

שוב נוכל למצוא את הגרסה האחרונה במוואן סנטרל.

3. תחילת העבודה

בחלק הבא הבא נסקור את השלבים הבסיסיים הדרושים לכתיבת מבחן פשוט.

נתחיל בבדיקת הפשטים ברכות משאב בשרת שלנו:

@Path ("/ greetings") ברכה בכיתה ציבורית {@GET @Path ("/ hi") ציבורי מחרוזת getHiGreeting () {להחזיר "hi"; }} 

3.1. הגדרת התצורה של המבחן

בואו נגדיר את כיתת הבדיקה שלנו:

מחלקה ציבורית GreetingsResourceIntegrationTest מרחיב את JerseyTest {@Override מוגן יישום להגדיר () {להחזיר ResourceConfig חדש (Greetings.class); } // ...} 

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

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

3.2. כותב את המבחן הראשון שלנו

נתחיל בבדיקת בקשת GET פשוטה מממשק ה- API לברכה שלנו:

@ מבחן ציבורי בטל givenGetHiGreeting_whenCorrectRequest_thenResponseIsOkAndContainsHi () {תגובה תגובה = יעד ("/ ברכות / היי"). בקשה () .get (); assertEquals ("תגובת Http צריכה להיות 200:", Status.OK.getStatusCode (), response.getStatus ()); assertEquals ("סוג תוכן Http צריך להיות:", MediaType.TEXT_HTML, response.getHeaderString (HttpHeaders.CONTENT_TYPE)); תוכן מחרוזת = response.readEntity (String.class); assertEquals ("תוכן התגובה הוא:", "היי", תוכן); } 

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

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

  1. שלח בקשת HTTP GET אל '/ ברכות / היי'
  2. בדוק את קוד המצב של HTTP וכותרות התגובה מסוג התוכן
  3. בדוק את תוכן התגובה מכיל את המחרוזת "היי"

4. בדיקת GET כדי לאחזר משאבים

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

4.1. קבל JSON רגיל

בדוגמה שלהלן אנו עובדים עם גוף התגובה כמחרוזת JSON רגילה:

@Test הציבור בטל givenFruitExists_whenSearching_thenResponseContainsFruit () {final String json = target ("fruit / search / strawberry"). בקשה () .get (String.class); assertThat (json, containString ("{\" name \ ": \" strawberry \ ", \" weight \ ": 20}")); }

4.2. קבל ישות במקום JSON

אנו יכולים גם למפות את התגובה ישירות למחלקה של ישות משאבים - לדוגמא:

 @Test הציבור בטל givenFruitExists_whenSearching_thenResponseContainsFruitEntity () {final fruit entity entity = target ("fruit / search / strawberry"). בקשה () .get (Fruit.class); assertEquals ("שם פרי:", "תות", entity.getName ()); assertEquals ("משקל פרי:", Integer.valueOf (20), entity.getWeight ()); }

הפעם, אנו מציינים את סוג ה- Java אליו יש להמיר ישות התגובה לקבל שיטה - א פרי לְהִתְנַגֵד.

5. בדיקת POST ליצירת משאבים

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

5.1. פוסט רגיל JSON

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

@ מבחן חלל ציבורי givenCreateFruit_whenJsonIsCorrect_thenResponseCodeIsCreated () {Response response = target ("fruit / created"). בקשה () .post (Entity.json ("{\" name \ ": \" תות \ ", \" משקל \ ": 20} ")); assertEquals ("תגובת Http צריכה להיות 201", Status.CREATED.getStatusCode (), response.getStatus ()); assertThat (response.readEntity (String.class), containString ("פרי נשמר: פרי [שם: צבע תות: null]")); }

בדוגמה שלעיל, אנו משתמשים ב- הודעה שיטה שלוקחת יֵשׁוּת פרמטר אובייקט. אנו משתמשים בנוח ג'סון שיטה ליצירת ישות ממחרוזת JSON המתאימה.

5.2. ישות פוסט במקום JSON

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

@ מבחן הריק ציבורי givenCreateFruit_whenFruitIsInvalid_thenResponseCodeIsBadRequest () {פרי פרי = פרי חדש ("אוכמניות", "סגול"); fruit.setWeight (1); תגובה תגובה = יעד ("פרי / צור"). בקשה (MediaType.APPLICATION_JSON_TYPE). פוסט (Entity.entity (פרי, MediaType.APPLICATION_JSON_TYPE)); assertEquals ("תגובת Http צריכה להיות 400", 400, response.getStatus ()); assertThat (response.readEntity (String.class), containString ("משקל הפרי חייב להיות 10 ומעלה"); }

הפעם אנו משתמשים ב- יֵשׁוּת שיטה לפרסום ישות ה- Fruit שלנו ולציין גם את סוג המדיה כ- JSON.

5.3. הגשת טפסים באמצעות POST

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

@ מבחן הריק פומבי givenCreateFruit_whenFormContainsNullParam_thenResponseCodeIsBadRequest () {Form form = Form חדש (); form.param ("שם", "תפוח"); form.param ("צבע", null); תגובה תגובה = יעד ("פרי / צור"). בקשה (MediaType.APPLICATION_FORM_URLENCODED). פוסט (Entity.form (טופס)); assertEquals ("תגובת Http צריכה להיות 400", 400, response.getStatus ()); assertThat (response.readEntity (String.class), containString ("צבע הפרי לא יכול להיות ריק")); }

באופן דומה, אנו משתמשים ב- יֵשׁוּת בכיתה אך הפעם העבירו טופס המכיל מספר פרמטרים לבקשת ההודעה שלנו.

6. בדיקת פעלות HTTP אחרות

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

בואו נראה דוגמה פשוטה של ​​PUT:

@Test ציבורי בטל givenUpdateFruit_whenFormContainsBadSerialParam_thenResponseCodeIsBadRequest () {Form form = Form חדש (); form.param ("סדרתי", "2345-2345"); תגובה תגובה = יעד ("פרי / עדכון"). בקשה (MediaType.APPLICATION_FORM_URLENCODED) .put (Entity.form (טופס)); assertEquals ("תגובת Http צריכה להיות 400", 400, response.getStatus ()); assertThat (response.readEntity (String.class), containString ("המספר הסידורי של פרי אינו חוקי")); }

ברגע שקראנו ל- בַּקָשָׁה אנו יכולים להפעיל כל שיטת HTTP על אובייקט הבקשה הנוכחי.

7. תכונות נוספות

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

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

מחלקה ציבורית FruitResourceIntegrationTest מרחיב את JerseyTest {@Override מוגן יישום להגדיר () {הפעל (TestProperties.LOG_TRAFFIC); הפעל (TestProperties.DUMP_ENTITY); // ...

כאשר אנו יוצרים ומגדירים את יישום ג'רזי שלנו בבדיקה. אנו יכולים גם לאפשר מאפיינים נוספים. במקרה זה אנו מאפשרים שני מאפייני רישום - LOG_TRAFFIC ו DUMP_ENTITYאשר יספק מידע שימושי נוסף על רישום ואיתור באגים במהלך ריצות הבדיקה.

8. מיכלים נתמכים

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

  • מיכל בזיכרון
  • HttpServer מבית Oracle JDK
  • מיכל פשוט (org.simpleframework.http
  • מיכל מזח (org.eclipse.jetty)

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

9. מסקנה

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

בחלק הבא ראינו כיצד לכתוב בדיקות למגוון נקודות קצה של GET ו- POST API. לבסוף, בדקנו כמה תכונות נוספות והמכולות שתומכות בה מסגרות הבדיקה של ג'רזי.

כמו תמיד, קוד המקור המלא של המאמר זמין באתר GitHub.


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