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

1. בדיקות End To End בסביבת Micro Services הן הרבה יותר יקרות מאשר בסביבת מונולית (ולא שבמונולית הן היו זולות). עיקר העלות הוא הקושי להעלות מערכת מלאה ויציבה התואמת למה שיש בגירסת הפרודקשן.

2. למרות המחיר העצום, אם נצליח להקים תשתית של בדיקות End To End אלה הולכות להיות הבדיקות שיתנו לנו את הביטחון הגדול ביותר שהמערכת אכן עובדת. פה יש כל מיני טכניקות בתוך המשפחה שנקראת Testing In Production, כמו למשל לשכפל את סביבת הפרודקשן ולבדוק בעותק, או אפילו לייצר סביבה מקבילה (Shadow) לפרודקשן ולבדוק שם.

3. בעיות חדשות של E2E Tests לסביבת Micro Services: אין מי שיתחזק אותן, כי כישלון בבדיקה הוא תמיד חוצה צוותים; ושינויים מהירים במערכת מביאים לזה שהבדיקות מאוד לא יציבות. לכן בדיקות E2E יוצרות תלות בין צוותי, וזה בדיוק מה שרצינו לברוח ממנו כשהלכנו לכתוב Micro Services.

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

5. בכתיבת Component Tests לרוב נבצע Mock לסרביסים האחרים. פריימוורק בשם Pact מאפשר בצורה אוטומטית ליצור מתוך המוקים האלה מסמכי בדיקות עבור כותבי הסרביסים האחרים (הספקים שלנו) כדי שהם יוכלו להיות רגועים שהם לא שוברים לנו את הסרביס. בדיקות כאלה נקראות Contract Tests, ומסתבר שגם הן די יקרות לתחזוקה, אבל עדיין פחות יקרות מ E2E.

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

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