כתיבה של מפעיל בדיקות ב-Tradefed

בדף הזה נסביר איך לכתוב מפעיל בדיקות חדש ב-Tradefed.

רקע

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

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

מינימום: הטמעת הממשק

הדרישה המינימלית כדי לעמוד בדרישות לכלי להרצת בדיקות ב-Tradefed היא הטמעה של ממשק IRemoteTest, ובאופן ספציפי יותר של השיטה run(TestInformation testInfo, ITestInvocationListener listener).

זוהי השיטה שמופעל על ידי ערכת הכלי כשמשתמשים ב-Test Runner, בדומה ל-Runnable של Java.

כל חלק מהשיטה הזו נחשב לחלק מההפעלה של מפעיל הבדיקות.

דיווח על תוצאות מכלי הבדיקה

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

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

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

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

הערה: קשה יותר להטמיע ריצה שמתבססת על רצף האירועים, אבל מומלץ לעשות זאת בגלל היתרונות שמפורטים למעלה.

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

• testRunStarted: הודעה על התחלת קבוצה של מקרים לבדיקה שקשורים זה לזה.
  • testStarted: הודעה על התחלת מקרה בדיקה.
  • testFailed/testIgnored: הודעה על שינוי המצב של תיק הבדיקה שנמצא בטיפול. תרחיש בדיקה ללא שינוי במצב נחשב כעבר בהצלחה.
  • testEnded: הודעה על סיום מקרה הבדיקה.
• testRunFailed: הודעה על כך שהסטטוס הכולל של קבוצת בדיקות התוכנה הוא כשל. הרצת בדיקה יכולה להיות עובר או נכשל ללא קשר לתוצאות של תרחישי הבדיקה, בהתאם למה שההרצה הייתה אמורה לצפות. לדוגמה, קובץ בינארי שמריץ כמה תרחישי בדיקה יכול לדווח על כל תרחישי הבדיקה שעוברים, אבל עם קוד יציאה של שגיאה (מכל סיבה שהיא: קבצים שדלפו וכו').
• testRunEnded: הודעה על סיום הקבוצה של מקרים לבדיקה.

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

קריאות חזרה (callbacks) של תרחישי בדיקה (testStarted,‏ testEnded וכו') הן אופציונליות. יכול להיות שתתבצע הפעלת בדיקה ללא תרחישי בדיקה.

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

דיווח על יומנים מכלי הבדיקה

אם אתם כותבים את מחלקת הבדיקה או את ה-runner של Tradefed בעצמכם, תצטרכו להטמיע את IRemoteTest ולקבל ITestInvocationListener באמצעות השיטה run(). אפשר להשתמש במאזין הזה כדי לתעד קבצים באופן הבא:

    listener.testLog(String dataName, LogDataType type_of_data, InputStreamSource data);

בדיקה באמצעות מכשיר

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

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

• IDeviceTest מאפשרת לקבל את האובייקט ITestDevice שמייצג את המכשיר שנבדק, ומספקת את ה-API ליצירת אינטראקציה איתו.
• IBuildReceiver מאפשר לבדיקה לקבל את האובייקט IBuildInfo שנוצר בשלב ספק ה-build, שמכיל את כל המידע והפריטים הקשורים להגדרת הבדיקה.

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

בדיקה במספר מכשירים

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

כדי לכתוב מפעיל בדיקות שיכול להשתמש במספר מכשירים, צריך להטמיע את IMultiDeviceTest, שמאפשר לקבל מפה של ITestDevice ל-IBuildInfo שמכילה את הרשימה המלאה של ייצוגי המכשירים ואת פרטי ה-build המשויכים להם.

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

בדיקות שמכירות את ההגדרות שלהן

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

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

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

כדי להטמיע את מפעיל הבדיקות, תצטרכו להטמיע את IConfigurationReceiver כדי לקבל את האובייקט IConfiguration.

כלי גמיש להרצת בדיקות

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

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

התמיכה בסינון מתוארת בממשק ITestFilterReceiver, שמאפשר לקבל קבוצות של מסנני include ו-exclude לבדיקות שצריך להריץ או לא צריך להריץ.

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

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