בדיקת ממשקי API באינטרנט עם אוספי דוור
1. הקדמה
כדי לבדוק באופן יסודי ממשק API אינטרנטי, אנו זקוקים לאיזשהו לקוח אינטרנט כדי לגשת לנקודות הקצה של ה- API. דוור הוא כלי עצמאי שמפעיל ממשקי API של רשת האינטרנט על ידי ביצוע בקשות HTTP מחוץ לשירות.
כשמשתמשים בדוור, איננו צריכים לכתוב קוד תשתית לקוח HTTP כלשהו רק לצורך הבדיקה. במקום זאת, אנו יוצרים סוויטות בדיקה הנקראות אוספים ונותנים לדוור לדו"ח להתקשר עם ה- API שלנו.
במדריך זה נראה כיצד ליצור אוסף דוור שיכול לבדוק REST API.
2. התקנה
לפני שנתחיל באוסף שלנו, נצטרך להגדיר את הסביבה.
2.1. מתקין את הדוור
דואר זמין עבור Linux, Mac ו- Windows. ניתן להוריד את הכלי ולהתקין אותו מאתר הדוור.
לאחר ביטול מסך הפתיחה, אנו יכולים לראות את ממשק המשתמש:
2.2. הפעלת השרת
דוור זקוק לשרת HTTP חי כדי לעבד את בקשותיו. לצורך הדרכה זו נשתמש בפרויקט Baeldung הקודם, אביב-מנוחה-אתחול, אשר זמין ב- GitHub.
כפי שאנו יכולים לנחש מהכותרת, אביב-מגף-מנוחה הוא יישום Boot Boot. אנו בונים את האפליקציה עם מטרת Maven להתקין. לאחר בנייתנו, אנו משיקים את השרת עם מטרת Maven המותאמת אישית קפיץ אתחול: לרוץ.
כדי לוודא שהשרת פועל, אנו יכולים להיכנס לכתובת URL זו בדפדפן שלנו:
// localhost: 8082 / spring-boot-rest / auth / foosשירות זה משתמש במסד נתונים בזיכרון. כל הרשומות מנוקות כאשר השרת נעצר.
3. יצירת אוסף דוור
אוסף בדוור הוא סדרה של בקשות HTTP. דוור שומר כל היבט בבקשות, כולל כותרות וגופי הודעות. לָכֵן, אנו יכולים להריץ את הבקשות ברצף כמבחנים אוטומטיים למחצה.
נתחיל ביצירת אוסף חדש. אנו יכולים ללחוץ על החץ הנפתח ב חָדָשׁ כפתור ובחר אוסף:
כאשר צור אוסף חדש שיח מופיע, אנו יכולים למנות את האוסף שלנו "מבחן ה- API של foo". לבסוף, אנו לוחצים על לִיצוֹר כפתור כדי לראות את האוסף החדש שלנו מופיע ברשימה משמאל:
לאחר יצירת האוסף שלנו, אנו יכולים לרחף מעל הסמן כדי לחשוף שני כפתורי תפריט. כפתור החץ פותח לוח ימינה משוך המספק גישה ל- אוסף רץ. לעומת זאת, כפתור האליפסה פותח תפריט נפתח המכיל מספר פעולות באוסף.
4. הוספת בקשת POST
4.1. יצירת בקשה חדשה
עכשיו שיש לנו אוסף ריק, בואו נוסיף בקשה שתגיע ל- API שלנו. באופן ספציפי, בואו נשלח הודעת POST ל- URI / auth / foos. לעשות את זה, אנו פותחים את תפריט האליפסה באוסף שלנו ובוחרים הוסף בקשה.
כאשר שמור בקשה מופיע תיבת דו-שיח, בוא נספק שם תיאורי, כגון "הוסף foo ”. לאחר מכן לחץ על הלחצן שמור למבחן ה- API של foo.
לאחר יצירת הבקשה, אנו יכולים לראות שהאוסף שלנו מציין בקשה אחת. עם זאת, אם האוסף שלנו לא הורחב, אנו עדיין לא יכולים לראות את הבקשה. במקרה כזה, נוכל ללחוץ על האוסף כדי להרחיב אותו.
כעת, עלינו לראות את הבקשה החדשה המופיעה תחת האוסף שלנו. אנו יכולים לראות כי הבקשה החדשה, כברירת מחדל, היא HTTP GET, וזה לא מה שאנחנו רוצים. נתקן זאת בסעיף הבא:
4.2. עריכת הבקשה
כדי לערוך את הבקשה, בוא נלחץ עליה ובכך נטען אותה בכרטיסייה עורך הבקשה:
למרות שלעורך הבקשות יש אפשרויות רבות, אנו זקוקים לעת עתה רק לכמה מהן.
ראשית, נשתמש בתפריט הנפתח כדי לשנות את השיטה מ- GET ל- POST.
שנית, אנו זקוקים לכתובת אתר. מימין לתפריט הנפתח שומרת תיבת טקסט עבור כתובת ה- URL לבקשה. אז בואו נכנס לזה עכשיו:
// localhost: 8082 / spring-boot-rest / auth / foosהשלב האחרון הוא לספק גוף מסר. מתחת לכתובת ה- URL שורת כותרות לשוניות. נלחץ על גוּף כותרת הכרטיסייה כדי להגיע לעורך הגוף.
בתוך ה גוּף לשונית, ממש מעל אזור הטקסט, יש שורה של כפתורי בחירה נפתחת. אלה שולטים בעיצוב וסוג התוכן של הבקשה.
השירות שלנו מקבל נתוני JSON, לכן אנו בוחרים את ה- גלם כפתור רדיו. בתפריט הנפתח מימין, אנו מיישמים את JSON (יישום / json) סוג תוכן.
לאחר הגדרת הקידוד וסוג התוכן, אנו מוסיפים את תוכן ה- JSON שלנו לאזור הטקסט:
{"name": "רובוטריקים"}לסיום, בואו נשמור לשמור את השינויים שלנו על ידי לחיצה Ctrl-S או להכות את להציל לַחְצָן. ה להציל הכפתור ממוקם מימין ל לִשְׁלוֹחַ לַחְצָן. לאחר שנשמור, אנו יכולים לראות שהבקשה עודכנה ל- POST ברשימה משמאל:
5. הפעלת הבקשה
5.1. הפעלת בקשה יחידה
כדי להפעיל בקשה אחת, אנו פשוט לוחצים על ה- לִשְׁלוֹחַ לַחְצָן מימין לכתובת ה- URL. ברגע שאנחנו לוחצים לִשְׁלוֹחַ, לוח התגובות ייפתח מתחת ללוח הבקשות. ייתכן שיהיה צורך לגלול מטה כדי לראות את זה:
בואו נבדוק את התוצאות שלנו. באופן ספציפי, בסרגל הכותרת אנו רואים שהבקשה שלנו הצליחה עם הסטטוס 201 נוצר. יתר על כן, גוף התגובה מראה כי שלנו רוֹבּוֹטרִיקִים הרשומה קיבלה מזהה של 1.
5.2. באמצעות אוסף האוסף
בניגוד ל לִשְׁלוֹחַ כפתור, רץ האוסף יכול לבצע אוסף שלם. כדי להפעיל את רץ האוסף, אנו מעבירים את הסמן מעל שלנו מבחן ה- API של foo אוסף ולחץ על החץ למשוך ימינה. בחלונית הימנית למשוך אנו יכולים לראות א לָרוּץ כפתור, אז בואו נלחץ על זה:
כאשר אנו לוחצים על לָרוּץ כפתור רץ האוסף נפתח בחלון חדש. מכיוון שהשקנו אותו מהאוסף שלנו, הרץ כבר מאותחל לאוסף שלנו:
רץ האוסף מציע אפשרויות המשפיעות על ריצת המבחן, אך לא נצטרך אותן לתרגיל זה. בוא נלך ישירות אל הפעל בדיקת API של foo כפתור בתחתית ולחץ על זה.
כאשר אנו מריצים את האוסף, התצוגה משתנה ל הפעל תוצאות. מהמבט הזה, אנו רואים רשימת בדיקות המסומנות כירוק להצלחה ואדום בגלל כישלון.
למרות שבקשתנו נשלחה, הרץ מציין שאפס מבחנים עברו ואפס מבחנים נכשלו. הסיבה לכך היא שעדיין לא הוספנו בדיקות לבקשתנו:
6. בדיקת התגובה
6.1. הוספת בדיקות לבקשה
ליצירת מבחן, נחזור ללוח עריכת הבקשות בו בנינו את שיטת ה- POST שלנו. אנו לוחצים על בדיקות הכרטיסייה שנמצאת מתחת לכתובת האתר. כאשר אנו עושים זאת, חלונית הבדיקות מופיעה:
בחלונית Tests אנו כותבים JavaScript אשר יבוצע עם קבלת התגובה מהשרת.
דואר מציע משתנים מובנים המספקים גישה לבקשה ולמענה. יתר על כן, ניתן לייבא מספר ספריות JavaScript באמצעות לִדרוֹשׁ() תחביר.
יש הרבה יותר מדי תכונות סקריפט בכדי לכסות במדריך זה. עם זאת, התיעוד הרשמי של הדוור הוא מקור מצוין בנושא זה.
נמשיך להוסיף שלוש בדיקות לבקשתנו:
pm.test ("מצב הצלחה", () => pm.response.to.be.success); pm.test ("השם נכון", () => pm.expect (pm.response.json (). שם) .to.equal ("רובוטריקים")); pm.test ("id הוקצה", () => pm.expect (pm.response.json (). id) .to.be.not.null);כמו שאנו יכולים לראות, בדיקות אלה עושות שימוש בכל העולם אחר הצהריים מודול המסופק על ידי הדוור. בפרט, המבחנים משתמשים pm.test (), pm.expect (), ו תגובת pm.
ה pm.test () פונקציה מקבלת תווית ופונקציה קביעה, כמו לְצַפּוֹת(). אנחנו משתמשים pm.expect () לקבוע תנאים על תוכן התגובה JSON.
ה תגובת pm האובייקט מספק גישה למאפיינים ופעולות שונות בתגובה שהוחזרה מהשרת. המאפיינים הזמינים כוללים בין השאר את מצב התגובה ותוכן JSON.
כמו תמיד, אנו שומרים את השינויים שלנו באמצעות Ctrl-S או ה להציל לַחְצָן.
6.2. הפעלת המבחנים
עכשיו כשיש לנו את הבדיקות, בוא נפעיל את הבקשה שוב. לוחץ על לִשְׁלוֹחַ כפתור מציג את התוצאות ב תוצאות מבחן הכרטיסייה של לוח התגובה:
כמו כן, רץ האוסף מציג כעת את תוצאות הבדיקה שלנו. באופן ספציפי, הסיכום בפינה השמאלית העליונה מציג את המעודכן עבר ו נִכשָׁל סך הכל. מתחת לסיכום יש רשימה המציגה כל בדיקה עם הסטטוס שלה:
6.3. צופה בקונסולת הדוור
ה קונסולת הדוור הוא כלי שימושי ליצירת וסקריפטים באגים. אנחנו יכולים למצוא את הקונסולה מתחת ל- נוף תפריט עם שם הפריט הראה את קונסולת הדוור. עם השקת המסוף נפתח בחלון חדש.
בזמן שהקונסולה פתוחה, היא מתעדת את כל בקשות ותגובות ה- HTTP. יתר על כן, כאשר סקריפטים משתמשים console.log (), ה קונסולת הדוור מציג הודעות אלה:
7. יצירת רצף בקשות
עד כה התמקדנו בבקשת HTTP אחת. עכשיו, בואו נראה מה אנחנו יכולים לעשות עם מספר בקשות. על ידי שרשור סדרת בקשות, אנו יכולים לדמות ולבדוק זרימת עבודה של שרת לקוח.
בקטע זה, נניח את מה שלמדנו על מנת ליצור רצף של בקשות. באופן ספציפי, נוסיף שלוש בקשות נוספות לבצע לאחר בקשת ה- POST שכבר יצרנו. אלה יהיו GET, DELETE ולבסוף, GET נוסף.
7.1. לכידת ערכי תגובה במשתנים
לפני שניצור את הבקשות החדשות שלנו, בואו ונבצע שינוי בבקשת ה- POST הקיימת שלנו. מכיוון שאנחנו לא יודעים איזה מזהה השרת יקצה לכל אחד מהם foo למשל, אנו יכולים להשתמש במשתנה כדי ללכוד את המזהה שהוחזר על ידי השרת.
כדי לתפוס מזהה זה, נוסיף שורה אחת נוספת בסוף תסריט הבדיקה של בקשת POST:
pm.variables.set ("id", pm.response.json (). id);ה pm.variables.set () פונקציה לוקחת ערך ומקצה אותו למשתנה זמני. במקרה זה אנו יוצרים תְעוּדַת זֶהוּת משתנה לאחסון ערך המזהה של האובייקט שלנו. לאחר הגדרתנו, אנו יכולים לגשת למשתנה זה בבקשות מאוחרות יותר.
7.2. הוספת בקשת GET
כעת, תוך שימוש בטכניקות מהסעיפים הקודמים, בואו להוסיף בקשת GET לאחר בקשת POST.
עם בקשת GET זו, אנו נאחזר אותה foo למשל שנוצרה בקשת ה- POST. בואו נקרא את בקשת ה- GET הזו כ- “קבל פוע“.
כתובת האתר של בקשת GET היא:
// localhost: 8082 / spring-boot-rest / auth / foos / {{id}}בכתובת אתר זו אנו מתייחסים ל תְעוּדַת זֶהוּת משתנה שקבענו בעבר במהלך בקשת POST. לפיכך, בקשת ה- GET צריכה לאחזר את אותה מופע שנוצר על ידי ה- POST.
משתנים, כאשר הם מופיעים מחוץ לתסריטים, מוזכרים באמצעות התחביר הכפול {{תְעוּדַת זֶהוּת}}.
מכיוון שאין גוף לבקשת GET, נמשיך ישירות אל ה- בדיקות הכרטיסייה. מכיוון שהמבחנים דומים, אנו יכולים להעתיק את המבחנים מבקשת ה- POST, ואז לבצע כמה שינויים.
קוֹדֶם כֹּל, אנחנו לא צריכים להגדיר את תְעוּדַת זֶהוּת משתנה שובאז בואו לא נעתיק את השורה הזו.
שנית, אנו יודעים לאיזה מזהה לצפות הפעם, אז בואו נאמת את זהותו. אנחנו יכולים להשתמש ב- תְעוּדַת זֶהוּת משתנה לעשות זאת:
pm.test ("מצב הצלחה", () => pm.response.to.be.success); pm.test ("השם נכון", () => pm.expect (pm.response.json (). שם) .to.equal ("רובוטריקים")); pm.test ("מזהה נכון", () => pm.expect (pm.response.json (). id) .to.equal (pm.variables.get ("id")));מכיוון שתחביר הסוגר הכפול אינו תקף ב- JavaScript, אנו משתמשים ב- pm.variables.get () פונקציה כדי לגשת ל תְעוּדַת זֶהוּת מִשְׁתַנֶה.
לבסוף, בואו נשמור את השינויים כפי שעשינו בעבר.
7.3. הוספת בקשת מחיקה
לאחר מכן נוסיף בקשת מחיקה שתסיר את foo אובייקט מהשרת.
נמשיך בהוספת בקשה חדשה לאחר ה- GET, והגדרת השיטה שלה למחוק. אנו יכולים למנות בקשה זו "למחוק foo“.
כתובת האתר של המחיקה זהה לכתובת ה- GET:
// localhost: 8082 / spring-boot-rest / auth / foos / {{id}}לתגובה לא יהיה גוף לבדיקה, אך אנו יכולים לבדוק את קוד התגובה. לכן לבקשת DELETE תהיה בדיקה אחת בלבד:
pm.test ("מצב הצלחה", () => pm.response.to.be.success);7.4. מאמת את המחיקה
לבסוף, בואו נוסיף עותק נוסף של בקשת GET כדי לוודא שהמחיקה באמת עבדה. הפעם, בואו נשכפל את בקשת ה- GET הראשונה שלנו במקום ליצור בקשה מאפס.
כדי לשכפל בקשה, אנו לוחצים לחיצה ימנית על הבקשה להצגת התפריט הנפתח. לאחר מכן, אנו בוחרים לְשַׁכְפֵּל.
לבקשה הכפולה תהיה המילה עותק צורף לשמו. בואו לשנות את שמו ל- “לאמת מחיקה”כדי למנוע בלבול. ה שנה שם אפשרות זמינה באמצעות לחיצה ימנית על הבקשה.
כברירת מחדל, הבקשה הכפולה מופיעה מיד לאחר הבקשה המקורית. כתוצאה מכך, נצטרך לגרור אותו מתחת לבקשה מחק.
השלב הסופי הוא שינוי המבחנים. עם זאת, לפני שנעשה זאת, בואו ננצל הזדמנות לראות מבחן כושל.
העתקנו את בקשת ה- GET והעברנו אותה לאחר ה- DELETE, אך עדיין לא עדכנו את הבדיקות. מכיוון שבקשת ה- DELETE הייתה צריכה למחוק את האובייקט, הבדיקות צריכות להיכשל.
בואו נדאג לשמור את כל הבקשות שלנו ואז ללחוץ נסה שוב ברץ האוסף. כצפוי, הבדיקות שלנו נכשלו:
עכשיו, לאחר שהעקיפה הקצרה שלנו הושלמה, בואו נתקן את הבדיקות.
על ידי בחינת הבדיקות שנכשלו, אנו יכולים לראות שהשרת מגיב עם סטטוס 500. לכן נשנה את הסטטוס במבחן שלנו.
יתר על כן, על ידי הצגת התגובה הכושלת ב- קונסולת הדוור, אנו למדים שהתגובה כוללת א גורם תכונה. יתר על כן, ה גורם המאפיין מכיל את המחרוזת "אין ערך נוכחי". אנחנו יכולים לבדוק גם את זה:
pm.test ("הסטטוס הוא 500", () => pm.response.to.have.status (500)); pm.test ("אין ערך קיים", () => pm.expect (pm.response.json (). סיבה) .to.equal ("אין ערך קיים"));7.5. מריץ את האוסף המלא
עכשיו לאחר שהוספנו את כל הבקשות, בואו נפעיל את האוסף המלא ברץ האוסף:
אם הכל התנהל לפי התוכנית, עלינו לערוך תשעה מבחנים מוצלחים.
8. ייצוא וייבוא האוסף
בעוד שדוור מאחסן את האוספים שלנו במקום פרטי ומקומי, ייתכן שנרצה לשתף את האוסף. לשם כך אנו מייצאים את האוסף לקובץ JSON.
ה יְצוּא הפקודה זמינה בתפריט האליפסה של האוסף. כאשר תתבקש לקבל גרסת קובץ JSON, בוא נבחר את הגרסה המומלצת האחרונה.
לאחר שנבחר את גרסת הקובץ, דואר יבקש שם קובץ ומיקום לאוסף המיוצא. אנו יכולים לבחור תיקייה בפרויקט GitHub שלנו, למשל.
כדי לייבא אוסף שיוצא בעבר, אנו משתמשים ב- יְבוּא לַחְצָן. אנו יכולים למצוא אותו בסרגל הכלים של חלון הדוור הראשי. כאשר הדוור מבקש מיקום קובץ, אנו יכולים לנווט לקובץ JSON שברצוננו לייבא.
ראוי לציין כי הדוור אינו עוקב אחר קבצים מיוצאים. כתוצאה מכך, הדוור אינו מציג שינויים חיצוניים עד שנייבא מחדש את האוסף.
9. מסקנה
במאמר זה השתמשנו בדוור כדי ליצור בדיקות חצי אוטומטיות עבור REST API. מאמר זה משמש אמנם מבוא לתכונות הבסיסיות של פוסטמן, אך בקושי גירדנו את פני יכולותיו. התיעוד המקוון של הדוור הוא משאב רב ערך לחקר מעמיק יותר.
האוסף שנוצר במדריך זה זמין ב- GitHub.
