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

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

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

שלב מיון

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

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

אפשר להיעזר בסימונים של שורת הפקודה (CLI) כדי לתקן בדיקות לא תקינות. לדוגמה, --enable-pixel-output-in-tests יעבד את ממשק המשתמש בפועל של הדפדפן.

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

מה אסור לעשות

חשוב לזכור סיבות נפוצות לכשלים ב-EXPECT__*, מלבד באגים בקוד הייצור:

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

[אל תבדקו את ההטמעה][לא הטמעה] אלא את ההתנהגות.

// 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.