3 דרכים לייצוב הבדיקות האוטומטיות שלנו

כל אחד מאיתנו חווה את זה.

כתבנו test אוטומטי, דיבגנו, הכל עבד מצוין.

הרצנו פעם אחת, וזה עבר באופן חלק.

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

הנושא הזה עייף וגרם לייאוש של עשרות בודקים ומפתחים.

למה אותה בדיקה פעם נכשלת ופעם עוברת מבלי כל סיבה הנראת לעין?

הדבר שאנחנו מדברים עליו כאן נקרא Flaky Tests והוא דבר חם מאוד בעולם האוטומציה היום.

מה זה Flaky Tests?

flaky tests או test flakiness הוא ביטוי המיצג חוסר יציבות של בדיקות אוטומטיות.

אם אותה בדיקה, באותם תנאים פעם אחת עברה ופעם אחרי נכשלה, הבדיקה היא flaky.

צעדים לייצוב הבדיקות האוטומטיות

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

דרך 1 - הפחתת כמות בדיקות ה - E2E/UI

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

אנחנו חייבים לשים לב שאיננו בודקים באמצעות בדיקת E2E לוגיקה שיכולה להבדק ברמה נמוכה יותר! (Unit tests/integration tests) עיקרון single responsibility מדגיש ואומר לנו שכל רכיב תוכנה (פעולה/מחלקה) צריך לעשות דבר אחד ורק אחד ואותו עיקרון תקף גם כאשר אנחנו מדברים על בדיקות. חשוב לזכור! ככל שיהיו שלבים ל test שלנו, כך אמינותו תהיה נמוכה יותר! זה פשוט מאוד, אבל שאנחנו עושים יותר דברים יש לנו יותר מקומות שאנחנו יכולים לטעות בהם.

דרך 2 - הורדת ה - Sleep מהבדיקות שלנו

ה-sleep הוא חבר טוב כמעט של כל מפתח אוטומציה בתחילת דרכו.

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

מה קרה?

לפעמים ישר אנחנו יכולים לראות את האיזור הבעייתי ולפעמים אנחנו מגלים שאנחנו תלויים ברכיב אחר (שרת מסוים/Database/דף שיעלה בדפדפן וכו')

אם ה test שלנו תלוי ברכיבים אחרים ובקבלת תשובה מהם sleep יהיה רעיון גרוע מאוד. העניין בתלות ברכיבים שונים הוא שקצב חזרת התשובה מהם משתנה מאוד (בגלל שוני במערכת הפעלה/תוכנה/חומרה/דפדפן/מהירות אינטרנט וכו’). כך אף פעם לא נוכל באמת לדעת כמה אנחנו צריכים לחכות!

מה לעשות במקום?

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

דרך 3 - הוספת לוגים

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

bool LoggedMethod(string str1, string str2)
{
    log.info(quot;Started logged method with parameters - str1: {str1}, str2: {str2}")
    bool returnValue = *method logic*
    log.info(quot;LoggedMethod return value is: {returnValue}")
    return returnValue
}

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

סיכום

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

נתראה בפוסט הבא!