כיצד להתמודד עם Flaky Tests | אמיר יצחקי

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

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

מה זה Flaky tests ? - זהו טסט שגם עובר וגם נופל מדי פעם ללא שינוי הקוד והסביבה שבו הוא רץ (טסטים שנופלים באופן קבוע אינם מוגדרים כ-Flaky Tests.)

הסיבות

 ישנם סיבות רבות להופעת מצב Flakiness, אלו חלק מהסיבות העיקריות להופעתן:

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

בעיות רשת

• תחזוקות ועדכונים בצד השרת
• תצורה (קונפיגורציה) של סביבת הטסטים

החשיבות בטיפול הבעיה

• עלות יקרה -בזבוז של זמן והשקעת מאמצים רבים בהבנת הנפילה.
• עיכוב ניכר בהוצאות גרסאות ושחרורן (במיוחד במתודולוגיות פיתוח אג׳ילי)
• בזבוז זמן לבניית Pipeline: CI/CD כאשר טסטים רבים נמצאים במצב פלנקי, האינסטינקט המיידי הוא להריץ

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

 תהליך הזיהוי

בדיקת תוצאות ההרצות של הטסטים בכמה הרצות לחקירת הסיבות:

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

אימוץ שיטות להפחתת ה-Flakiness

 לצערנו לא ניתן למגר לחלוטין את ה-Flaky - Tests  אבל ישנם מספר שיטות וכלים לצמצם את התופעה באופן משמעותי.

• להתמקד יותר בפיתוח של API ו-Unit tests לעומת UI-Tests, ברוב המערכות כמות הטסטים מסוג API ו-Unit testing צריכה להיות גבוה יותר יחסית למספר הטסטים ב-UI , כמו כן ה-Flakiness ב-API וב-Unit testing הוא נמוך משמעותית מול בדיקות ה-UI .
• בבדיקות UI יש להשתמש באסטרטגית תפיסת אלמנטים יעילה. כחלק מתפקידנו, עלינו הבודקים לבקש מצוות המפתחים ליצור אלמנטים עם מזהים ייחודיים. לחקור ולהבין טוב יותר את התשתית של האוטומציה: ישנן מספר תשתיות אוטומציה אשר נותנות מענה -ראוי להתמודדות ב-Flakiness לדוגמא : cypress נותנת מספר כלים (בתשלום) להתמודד עם המצב שאחד מהם הוא גילוי אוטומטי וסינון של הטסטים הללו.
• שימוש בכלי ניטור הנותנים תמיכה ל-FT לדוגמא : בעבר השתמשתי בכלי Report portal לייצור דוחות ריצה - מסתבר שאחד הפיצ'רים תומך בצורה מובנת ויעילה לדעתי ב-Flaky tests וזאת בעזרת דשבורד הרצה פשוט המתאר בצורה גרפית עד 30 ההרצות האחרונות של אותו טסט ודיווח האם הוא נכשל או עבר וכן את זמני ההרצה. באמצעות ניטור פשוט זה הצלחתי למצוא בקלות מספר טסטים של Flakiness בעקבות זמן הרצה ארוך שנבע מבעיה בנטוורק, בנוסף ניתן היה למצוא בקלות יחסית את הזמנים שלא היה כדאי להריץ את הטסטים הללו.
• הפחתת התלותיות בשירותים של צד שלישי – בחלק מבדיקות האינטגרציה וה-E2E אנו מסתמכים על מערכות שאינם בשליטתנו. אמנם לא נכון להפסיק לבדוק לחלוטין את הקישור למערכת החיצונית אבל ביכולתנו לצמצם את התלותיות של הטסטים שלנו בה. הצמצום נעשה בעזרת שימוש בכלים שמחקים את התנהגות המערכת החיצונית מבלי להזדקק לה – כלים נפוצים לדוגמא: שימוש ב-Mocks & Stubs
• ניקוי סביבת ההרצה לפני הרצה חדשה- לפעמים שימוש בזיכרון מטמון או לאחר הרצה של אחד הטסטים בהם נשמרים פרטי מידע כלשהם יכולים לגרום לנפילות בטסטים הבאים אחריהם, זהו סוג של Flaky test שקשה מאוד לזיהוי ולכן כדי לצמצם FT מסוג זה כדאי מאוד לדאוג למצבי הרצה בסביבות נקיות.

 לסיכום

 כאשר אנו מריצים כמות גדולה של טסטים לא ניתן להימנע מ - Flaky tests במיוחד בבדיקות UI ואינטגרציה אך גם בשאר סוגי שאר הבדיקות ניתן להיתקל בהם במינונים נמוכים יותר. במחקר [1]שנעשה בחברת גוגל העולמית כמות הטסטים המורצים לפני הטמעת קוד עומד על כ-4.2 מיליון הרצות, נמצא שאומנם רק כ-1% מהטסטים נופלים אך כמעט 16% מכל הטסטים שהורצו מוגדרים בדרגות שונות של Flaky Tests. כ- 84% מהבדיקות שעברו ממצב עובר למצב נכשל הוגדרו כ-Flaky Tests.

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

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

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

[1] https://static.googleusercontent.com/media/research.google.com/iw//pubs/archive/46593.pdf