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

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

רקע

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

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

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

כדי לעמוד בדרישות של Tradefed ככלי להרצת בדיקות, צריך להטמיע את הממשק 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 טיפוסי. הסיבה לכך היא שרצינו להשתמש במשהו בסיסי שמפתחים בדרך כלל מכירים.

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

אם אתם כותבים מחלקה או רץ משלכם לבדיקות 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 שמכיל את הרשימה המלאה של ייצוגי המכשירים ופרטי ה-build המשויכים שלהם.

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

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

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

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

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

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

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

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

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

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