כתיבת רכיב הרצה במבחןטרי

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

רקע

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

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

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

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

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

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

דיווח על תוצאות מההרצה של הניסוי

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

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

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

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

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

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

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

שמירה על הסדר הנכון של הקריאות החוזרות (callback) והקפדה על הסדר הנכון של הקריאות החוזרות היא האחריות של הכלי להרצת הניסוי. לדוגמה, צריך להקפיד להפעיל את testRunEnded במקרה של חריגות באמצעות סעיף finally.

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

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

דיווח על יומנים מהרצת הבדיקה

אם אתם כותבים מחלקה לבדיקה או הרצה משלכם ב-Trendified, צריך להטמיע את IremoteTest ולקבל ITestInvocationListener באמצעות ה-method 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 לבדיקות שצריך להריץ או לא צריך להריץ.

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

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