הבדיקות שוב לא מדויקות? כך תיפטרו מ-Flakey Tests

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

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

אז מה עושים?

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

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

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

בידוד טסטים (Test Quarantine) – פתרון נוסף שמאפשר להתגבר על Flaky Tests הוא שימוש בטכניקת הבידוד, שפותרת את החסרונות של פתרון הטסט החוזר ומציעה לבודד טסטים לא יציבים במקום להריץ אותם או להשאירם בתוך המערכת. כפי שמשתמע מהשם, את הטסט הלא יציב יש להוציא מהסוויטה ולשים ב"הסגר". ניתן לייצר קבוצה ייעודית לכך ולשייך אליה את כל הטסטים שאינם יציבים וכאשר רוצים לבצע הרצה אפשר לא לכלול את קבוצה זו בתוכה, על מנת שהיא לא תשפיעה על תוצאות הטסטים.

תחקור – בדרך כלל מציאת שורש הבעיה שמביאה לחוסר יציבות בבדיקות טמונה בתהליך מורכב, שדורש לבצע תחקור על מנת לבחון את סיבות הליבה לכך שהטסטים מייצרים אי דיוקים ולאחר מכן להחזיר אותם לתוך הסוויטה המרכזית. כיצד נעשית החקירה? אוספים את כל המידע הרלוונטי שאפשר: צילומי מסך, Database Dumps, System Dumps, HTTP Dumps ו- Log Files (בהתאם למערכת ולתחום בו פועלים כמובן), ובוחנים את הכל לעומק. חשוב לאסוף כל מידע שיכול להיות רלוונטי, גם אם לא לטסט הספציפי שנבדק.

סטטוס Fail to Verify – חברת Dropbox הגיעה לפתרון בטכניקה שנקראת Fail to Verify Test Status – סטטוס חדש של טסטים שהוא פתרון משלים לתהליך הבידוד. לפי הטכניקה הזו לא מסתכלים על הטסט כעל מכלול שלא משנה היכן התגלתה בו אי-היציבות, אלא מבחינים בין טסט שנכשל בחלק הארי שלו (מה שרצינו לבדוק), לבין טסט שנכשל בשלב נלווה. כך, במקום להתעכב על התהליך כולו ולהכניס לבידוד טסט שמתנהג באופן לא-יציב בחלק שאינו רלוונטי לבדיקה, מזקקים את הטסט רק לחלק שמעניין אותנו לבחון ובודקים האם הוא עבר או נכשל בחלק זה בלבד. הפעולה המרכזית בטכניקה הזו היא מיון הטסטים, באמצעותה ניתן לצמצם את מספר הטסטים שנכנסים לבידוד.

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

הכותב הינו מנהל טכנולוגיות ראשי (CTO) ב-Top-Q, זרוע האוטומציה של מטריקס.