מפתחים בסביבת Microservices? כך נכון לבדוק את הקוד שלכם

מפתחים בסביבת Microservices? כך נכון לבדוק את הקוד שלכם
מאת: ליאור כץ, 31.1.21, 14:56

הכל על פיתוח בסביבת Microservices, שהעצים את כל השיטות והחדשנות בתחום הפיתוח בשנים האחרונות, תוך היעזרות בתרשים פירמידת הבדיקות, שמכונה גם "Testing Life Cycle".
 
רגע לפני שאנו צוללים לעולם הבדיקות בסביבת Microservices, יש להבין מה המשמעות של פיתוח בסביבה כזו. עד לא מזמן, סביבת הפיתוח הייתה סביבה מונוליטית, שמשמעותה היא סביבה קבועה ואחידה, שכוללת בסיס קוד יחיד, שירות (Service) אחד, עם מארח אחד, בסיס נתונים יחיד וטכנולוגיה אחידה.

בשיטה המונוליטית כל חלקי הקוד משתלבים (Linking) אחד עם השני. כך, שלא ניתן לשלב חלקי קוד בשפות אחרות. לאחר העלאה של קוד חדש בפרויקט, יש לבדוק כל חלק ממנו בנפרד ולהריץ עליו בדיקות, כדי שנוכל לוודא, שהוא לא "שובר" חלקים אחרים בקוד וכתוצאה מכך פוגם במוצר.

ההבדל המשמעותי בין פיתוח בסביבה מונוליטית לפיתוח בסביבת Microservices הוא, שבסביבה השנייה כל חלק בקוד נכתב באופן עצמאי לחלוטין. כלומר, החלקים השונים בקוד יכולים להיות כתובים בשפות תכנות שונות או תחת פלטפורמות אחרות, כאשר ניתן לחבר אותן ע"י ממשק Rest API.

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

 ונעבור לתחום הבדיקות..
כדי להסביר על תהליך הבדיקות עבור קוד המפותח בסביבת Microservices, ניעזר בתרשים פירמידת הבדיקות, שמכונה גם "Testing Life Cycle":
Unit Test - השלב הראשון בפירמידה הוא אינו ה-Unit Test הרגיל, שרבים מאיתנו מכירים. הסיבה לכך נעוצה בעובדה, שמדובר בפלטפורמה, שגם מייצרת יחידות בדידות ואוטונומיות, ולכן יש לחלק את ה-Unit test המוכר ל-2 חלקים:

1. Solitary Test - בדיקות יחידה, שניתן לבודד - בדיקות מסוג זה מתאימות כאשר רוצים לבודד את היחידות הנדרשות לבדיקה, ולא לערב את שאר היחידות. בדיקות אלו הן היעילות ביותר במושגים של מהירות ועלות הבדיקה.
2. Sociable Test - בדיקות יחידה המסתמכות על יחידות אחרות, כדי לאפשר את הפונקציונליות הרצויה. בדיקות אלו אינן מבודדות את יחידות הבדיקה אלא מסתמכות על יחידות אחרות, שחייבות להיות חלק מהבדיקה. לדוגמה: לצורך הרצת תהליך עסקי כלשהו ניתן להריץ בדיקה על פונקציונליות המסתמכת על פונקציונליות של יחידות אחרות.

Component Test - בדיקות אלו מאפשרות בדיקה מקצה לקצה או בדיקה של תהליך עסקי שלם, ומצויות בשלב השני בפירמידה. הן ,למעשה, בדיקות המיועדות לבחון כיצד יחידה אחת מבודדת מתקשרת עם יחידות אחרות, שהן שירות וירטואלי (Virtual Services). דהיינו, היחידות האחרות עדיין לא שלמות, או לא מפותחות, אך אפשר לדמות אותן ע"י Service Virtualization.

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

כדי לבצע בדיקות מסוג זה, ניתן להיעזר במספר כלים היכולים לדמות שירותים לצרכי בדיקה, ביניהם: Mockoon, Wiremock, Gini-Apps ונוספים.

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

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

בהיבט הפרקטי, בדיקות Contract Testing קלות מאוד לביצוע ויכולות למנוע נפילות של הרצות ותחקירים מיותרים. את הבדיקות ניתן לבצע באמצעות כלים שונים, כמו לדוגמה - Post Man.

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

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

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

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

במידה ובחרתם לעבור לסביבת פיתוח זו, יש לדאוג להתאים את שגרת הבדיקות לסביבת הפיתוח החדשה. שלבי הבדיקות השונים בנויים זה על זה ותלויים זה בזה. כך, שבשלב ב- Component Testing אפשר לדמות יחידות, שלא פותחו במלואן ע"י Service Virtualization, ולבדוק בשלב ה-Contract Testing את הקשר והפעילות בין היחידות. זה קריטי לקראת השלמת הבדיקות בשלבים הסופיים הכוללים בדיקות מקצה לקצה ובדיקות אינטגרציה. אלה, עשויים לחסוך זמן, מאמץ ובאגים מיותרים.

מאת: ליאור כץ, ינואר 2021.
מנהל טכנולוגיות ראשי בחטיבת בדיקות ואוטומציה של מטריקס