Microservices- The right way to test it

ליאור כץ, CTO מטריקס בדיקות ואוטומציה

כולם בכיוון של Microservices, אז בואו נבין איך בודקים את זה-

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

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

מה היה לנו עד היום? סביבה מונוליטית.

מוניליטי (תרגום מילון) – פסל או מבנה הבנוי מגוש אבן אחד.

טוב, אז פסל- אנחנו לא, אבל סביבת פיתוח מוניליטית אכן אומרת:

בסיס קוד יחיד, Service אחד, מארח אחד, DB אחד, טכנולוגיה אחידה (למשל כשהכל כתוב באותה שפת פיתוח).

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

ומה זה אומר פיתוח ב-Microservices?

כל MS (מיקרו סרביס) ייכתב באופן עצמאי לחלוטין. יש כאלה גם עם DB משלהם, זאת אומרת ששינויי תחזוקה או הרחבה יעשו לכל סרביס בנפרד, ללא שינוי ו/או נגיעה בסרביסים אחרים. הסרביס יכול להיות כתוב בשפה אחרת או בפלטפורמה שונה, כל עוד אפשר יהיה לחבר אותו לסרביסים אחרים, על ידי ממשק Rest API שאפשר יהיה לשלוח אליו פרמטרים דרך קובץ jason ו/או YAML, ולקבל בחזרה את הנתונים הדרושים.

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

אז מה… שנעבור בעצם לתחום הבדיקות עליו רצינו לדבר, לא?

בשביל שנהיה כולנו On the same page, הדבר הראשון שנציג שמתאר את הTLC (Testing Life Cycle) הקשור לMS זה הפירמידה של הבדיקות. שימו לב, התיאור של הפירמידה אומר שככל שאנחנו מתקדמים יותר לכיוון ראש הפירמידה, כך אנו אמורים להשקיע פחות Effort.

בואו נתקדם ונתחיל לפרש כל שלב- מה הוא אומר וכיצד הוא משפיע על השלב הבא בפירמידה.

Unit Test

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

1. Solitary Test – בדיקות יחידה בדידות, כפי שניתן לראות בתרשים למטה.

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

2. Sociable Test – בדיקות יחידה המסתמכות על יחידות אחרות, בכדי לאפשר את הפונקציונליות הרצויה.

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

Component Test

סוג זה של בדיקות מאפשר בדיקת E2E ו/או תהליך עסקי שלם, דרך הרצת כמה יחידות, כאשר למעשה הבדיקה היא ליחידה אחת מבודדת המתקשרת עם יחידות אחרות, שהן Virtual Services. דהיינו, היחידות האחרות עדיין לא שלמות, או לא מפותחות, ועדיין אפשר לדמות אותן על ידי Service Vitalization.

קיימים מספר כלים היכולים לעזור לנו לדמות Services לצרכי בדיקה:

Contract Test

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

שימו את החוזה בין Consumer A לבין ה-Provider, שהוא מה שכתוב בחוזה- במקרה הזה 2 שדות: First Name, ו-Email.

כמו כן, שימו לב שהחוזה בין Consumer B וה-Provider שונה, כך שהפעם החוזה בין שתי היחידות הוא 3 שדות: First name, Last Name, Address. למה בכלל אנחנו צריכים את הבדיקות האלה, מה הן מכסות לנו, ולמה כל כך כדאי לנו להתעסק בזה?

אז למה צריכים את זה?

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

מה הבדיקות מכסות לנו?

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

למה כדאי לנו להתעסק בזה?

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

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

* cDc = Consumer Driven Contract test

כמה כלים מומלצים שיכולים להיות רלוונטיים בנושא:

Integration & E2E Test

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

נעור כעת לשלב האחרון והכי מגניב שנקרא Canary Testing. מה זה ולמה זה קשור לקנריות?

Canary Test

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

אז מה הקשר לכנריות, ועוד יותר מה הקשר למכרות פחם?

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

אז מה היה לנו?

סביבה מוניליטית- OUT. מעכשיו מדברים ב-Microservices, המתנהגים כיחידות נפרדות ואוטונומיות בסביבת הפיתוח. את היחידות בודקים עם דגשים על ה-Shift Left לכיוון ה-Unit Test, שגם כאן בגלל החיבור בין ה-MS השונים אפשר לבדוק כיחידה אוטונומית, וכאחת המתחברת ומושפעת מה-MS האחרים. תזכרו את ה-Component Testing שנותנים לנו אפשרות לבדוק לפני שכל ה-MS מוכנים לפעולה, את ה-Contract Testing שיחסכו לכם המוני באגים בשיטת בדיקות פשוטה, ובדיקה שהיא קריטית בסביבת MS. לאחר מכן, זכרו את ה-Integration, ה-E2E, ולבסוף ה-Canary Testing.

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

 

מאת: ליאור כץ, CTO במטריקס בדיקות ואוטומציה.
מעוניינים לשמוע עוד מליאור? צרו קשר

רוצים לשמוע עוד? דברו איתנו

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