Chrome Chronicle מס' 2: להילחם בפרצות בדיקות

פרק 2: מאת וסילי במינכן (מאי 2019)
הפרקים הקודמים

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

שלב הטרייה

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

שלב ניפוי באגים

יש כמה דגלים של שורת הפקודה שיכולים לשמש לתיקון בדיקות בעייתיות. לדוגמה, --enable-pixel-output-in-tests יבצע רינדור בפועל של ממשק המשתמש של הדפדפן.

שימוש בכלים חלופיים אם הכלי לניפוי באגים נעלם את הנתונים השימושיים. זו שככלי לניפוי באגים, הבדיקה אף פעם לא תהיה בעייתית. במקרה כזה, הזן או base::debug::StackTrace יכולים להיות שימושיים.

// It takes 2 round trips between the UI and the background thread to complete.
SyncWithTheStore();
SyncWithTheStore();
CheckTheStore();

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

Submit TestPasswordForm();
// Wait until things settle down.
RunLoop().RunUntilIdle();
CheckCredentialPromptVisible();

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

SubmitTestPasswordForm();
WaitUntilCredentialPromptVisible();

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

שלב לאחר תיקון

אחרי תיקון הבדיקה, יש להריץ אותה מאות פעמים באופן מקומי. הקפידו לעקוב אחר Flakiness Portal.