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

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

רקע

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

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

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

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

השיטה הזו מופעלת על ידי ה-harness כשמשתמשים ב-test runner, בדומה ל-Java Runnable.

כל חלק בשיטה הזו נחשב לחלק מההרצה של כלי הבדיקה.

דיווח על תוצאות מ-Test Runner

השיטה run בממשק הבסיסי מעניקה גישה לאובייקט listener מסוג ITestInvocationListener. האובייקט הזה הוא המפתח לדיווח על תוצאות מובנות מ-test runner אל harness.

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

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

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

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

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

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

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

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

דיווח על יומנים מ-test runner

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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