בדיקות API אוטומטיות עם התממשקות לסלניום
API הם ראשי התיבות של Application Programming Interface, הפועל כממשק בין שני יישומים ומעניק יכולת לתקשר זה עם זה ללא קשר לשפות התכנות המשמשות לפיתוחם.
בדיקת API ממלאת תפקיד מכריע בתהליך פיתוח התוכנה שכן היא עוזרת לנו לבדוק את ההיגיון העסקי של האפליקציה עוד לפני שה-UI מוכן .שכן ,ממשק API שלא כמו כל היבט אחר של התוכנה הוא חסר GUI אך ההשפעה שלו ניכרת בכל התוכנה.
עבור קהילת הבודקים, בדיקת API Automation מהווה נישה חדשה, המורכבות של קבצי JSON גורמת לבדיקות API לא להיות מנוהלות בקוד, ולכן נראה פחות צוותים המנהלים קוד עבור זה.
מכאן, שזה המקום שבו אוטומציה נכנסת פנימה ומסייעת בבדיקת ממשקי API,כל מימוש הקריאות/ בקשות נכתבות פעם אחת לשימוש חוזר עתידי והתשתית בעצם נכתבת פעם אחת ומשמשת עבור כל API חדש שנרצה לממש עבורו בדיקה.
REST Assured
ישנם המון כלים עבור אוטומציה ל API ואחד המוכרים והשימושיים כיום הוא Postman
REST Assured היא אחת מספריות ה-Java הפופולריות ביותר המשמשות לכתיבת בדיקות ולניטור של בדיקות עבור שירותי האינטרנט RESTful. ישנם סוגים שונים של ממשקי API כגון SOAP, REST ו-RPC וכו'. אני אתמקד בבדיקת REST API באמצעות REST Assured .
הסיבה שבגינה אתמקד ב REST API באמצעות REST Assured, היא:
- קוד פתוח, מבוסס Java, ותומך הן בפורמט XML והן בפורמט JSON.
- משתלב היטב עם Maven, TestNG.
- תמיכה ב-DELETE, POST, GET, PUT, PATCH, OPTIONS ובכל הבקשות העיקריות.
- אימות התגובה שהתקבלה בהתבסס על Groovy ופילטור מתקדם בעזרת Gpath
- לספריה ישנן שיטות להביא נתונים כמעט מכל חלק של הבקשה והתגובה, ללא תלות במורכבות מבני ה-JSON.
- לצד התמיכה בכל שיטות ה-HTTP, הוא תומך גם בבקשות הכוללות OAuth ו-OAuth 2.0.
ישנן סיבות רבות מדוע מומלץ לכתוב בדיקה אוטומטית לרמת ה-API, אך הסיבה הטובה ביותר תהיה מהירות הביצוע המוגברת של בדיקות אלו בהשוואה לזו של בדיקות מבוססות GUI, יחד עם היקף הרחב יותר.
החלטתי לאמץ את התשתית לצוות שלי בזכות החיבוריות המאוד טובה עם סלניום.
פורמט של פונקציה
איך בעצם טסטים נכתבים ב-REST assured
BDD (Behavior Driven Development)
העיקרון של בדיקת BDD הוא מקרי המבחן הנכתבים בשפה טבעית ניתנת לקריאה בקלות גם על ידי מי שאינם מתכנתים.
כאשר נשלח את הפרמטרים הנכונים - Given
- ונבצע מתודה מסויימת When
- נצפה ל.. Then
בניית תשתית הפרויקט
נבנה פרויקט Maven בשימוש TestNG
- הוספת Rest Assured לקובץ pom
- Best Test
נבנה את ה-class הזה כאשר כל הטסטים שלנו יירשו (אותה השיטה כמו בסלניום)
API Function class
נממש את כל הקריאות העיקריות POST,GET,DELETE,PUT ב-class הנקרא API functions שייתן לנו שימוש של כל הפרויקט שלנו.
- בניה של טסטים (ארחיב בהמשך)
מניפולציות על התשובה המתקבלת מהשרת
- בדיקת הסטטוס המוחזר ע"י הקריאה
בעזרת הקוד נוכל להשוות את הסטטוס המוחזר ע"י קריאת הבקשה
- קבלת התשובה כולה כמחרוזת
בעצם כאן אנחנו משתמשים ב-asString לאחר קריאת ה-get והשמה למשתנה מסוג String
- ()jsonPath - חילוץ חלק מתוך התשובה המוחזרת מהשרת:
ניתן להגיע לחלק מן התשובה , לא משנה כמה קובץ ה- Json המתקבל הוא מורכב , וניתן להשוות, להדפיס או ליישם למשתנים שנרצה את החלק המוחזר.
דרך שימוש שנייה ב-response.path()<”element to find"> in Json” בעזרת extract()
פלטור מתקדם – Gpath
Rest assured משתמש ב-GPath שזוהי שפה לאיתור אלמנטים בתוך Json.
בהנחה שזה קובץ ה-Json שאנחנו מקבלים כתשובה ונרצה לחפש בתוכו בצורה מתקדמת 
שליחת בקשה לשרת – מספר דרכים
- אפשרות ראשונה :
שליחת גוף הבקשה כמחרוזת, שימוש ב-POST עם שליחת ה-URL המתאים.
- שליחת גוף הבקשה כמחרוזת, שימוש ב-POST שבנינו ב-API Functions (אם עקבתם כמו שצריך)
- שליחת אובייקט כבקשה ל-API
דרך זו אנו בעצם שולחים את הבקשה כאובייקט java מה שאנחנו בעצם שולחים זה "מראה" של קובץ Json לתוך class שניצור, דרך זאת היא אומנם מתוחזקת קוד יותר ודורשת מאיתנו מעקב על קבצי ה-json כלומר אם משתנה שם של ערך מסוים אנחנו בעצם צריכים לשנות גם את הקוד אצלנו. היתרון של זה שאנחנו לא צריכים להתעסק עם קבצי json או לפרסס אותם אנחנו פשוט עובדים pure java.
טיפ למשתמשי Postman
אינטגרציה עם סלניום
אחד הדברים שעזרו לי בבחירת Rest Assured על פני הכלים האחרים זאת אוטומציית ה-UI הממומשת אצלנו בקוד המבוסס Selenium & Java. כשהתחלתי לחשוב על מימוש לטסטים של ה-API, ראיתי במחקר שלי המון כלים אשר חלקם פשוטים יותר וחלקם טובים יותר, אך כשהבנתי שאפשר לעשות התממשקות מלאה בין האוטומציה שכבר קיימת לי בסלניום בחרתי את הכלי הזה.
ולמה?
- האפשרות להעמיק טסטים של GUI בבדיקות API על אותו המוצר (כבר נראה דוגמא)
- אפשרות ליצור טסט שמאפשר חיבור בין PI לבין UI (לדוגמא: יצירה של 100 משתמשים דרך קריאה של API ולאחר מכן לפתוח את הדפדפן ולהמשיך בטסטים של GUI על אותם משתמשים ואותה DATA
- אותה תשתית יכולה לשמש ל-2 הפרויקטים באוטומציה שניהם משתמשים Java, Maven & testNG
מבניות הפרויקט
המבניות שכבר הייתה קיימת לי עבור פרויקט הסלניום, עשתה את הדרך לבנות את הפרויקט API לקלה יותר. כל מה שהיה עלי לעשות זה להוסיף package חדש עבור ה-API, ולדברים משותפים כמו התממשקות עם דוחות אלור (Allure), קבצי מידע משותפים. כל ניהול קבצי XML המכילים את הטסטים, מנוהלים במקום אחד, ומכילים גם קובץ שישמש אותנו לראייה ב-Hi-level של כל הפרויקט הקיים שלנו גם עבור API וגם עבור UI.
האפשרות להעמיק טסטים של GUI בבדיקות API על אותו המוצר
בדיקות API
נוכל "לשחק" עם מנגנון ההורדה בתוכנה שלנו, לשלוח לדוגמא פורמטים שלא קיימים
בדיקות UI
יש לנו את האפשרות ללחוץ על כפתורי ההורדה רק לאלו שאנחנו רואים
לסיכום
לא לוותר על בדיקות API, להבין שהדרך לכתוב תשתית אוטומטית לבדיקות אלה היא קלה ולא מסובכת בייחוד אם אנחנו כבר מתחזקים תשתית עבור בדיקות UI. וגם אם לא, המאמר מכיל רק חלק קטן ממה שאפשר לעשות עם Rest assured שהופך את הבדיקות ותחזוק הקוד לממש פשוט.
אני מאמינה שצוות QA טוב הוא זה שיש בו לפחות איש אחד שעיקר תפקידו הוא פיתוח תשתית הבדיקה, תמיד תנסו לחשוב מעבר למה שאפשר לפתח בעצמנו כי באמת הדברים לא מסובכים.
לכל שאלה ניתן לפנות אלי בלינקדאין
