הפעלת הבדיקה היא יחידת הביצוע של תהליך ההפעלה. כאן מריצים בפועל את הבדיקות.
ממשקים
מפעילי הבדיקות מוגדרים באמצעות ממשק IRemoteTest, שמספק שיטה פשוטה ל-run
שאפשר להטמיע, ותתבצע קריאה אליה כשהבדיקה תופעל.
כך אפשר להגדיר את הרצת הבדיקה בצורה הפשוטה ביותר. אבל בפועל, לכותבי הבדיקות יהיה צורך במידע נוסף כדי לכתוב את הבדיקות בצורה נכונה, בדרך כלל מידע על ה-build והמכשיר. כאן נכנסים לתמונה הממשקים הבאים.
בסיס
שני הממשקים האלה הם הנפוצים ביותר כיום, כי הם מייצגים את הצרכים הבסיסיים של רוב הבדיקות.
- IBuildReceiver מאפשר לבדיקה לקבל את האובייקט
IBuildInfo
שנוצר בשלב build provider, שמכיל את כל המידע והפריטים הקשורים להגדרת הבדיקה. - IDeviceTest מאפשר ל-TF לקבל את האובייקט
ITestDevice
שמייצג את המכשיר בבדיקה ומספק API לאינטראקציה איתו.
הגדרות מתקדמות
יש ממשקים נוספים שמאפשרים אינטראקציה מורכבת יותר בין ערכת הבדיקות לבין הכלי להרצת הבדיקות:
- ITestFilterReceiver, שמאפשר לבדיקה לקבל קבוצת מסננים להרצת בדיקות מסוימות בלבד. האפשרות הזו שימושית להרצה של קבוצת משנה של הבדיקות.
- ITestCollector, שמאפשר למפעיל בדיקות להריץ את הבדיקות רק לצורך בדיקה ולא לבצע אותן בפועל. האפשרות הזו שימושית לאיסוף רשימה של כל תרחישי הבדיקה.
כלי בדיקה קיימים
כבר קיים מגוון סוגים של הרצות בדיקה, חלקם מיועדים לניסויים מהסוגים העיקריים:
- AndroidJUnitTest / InstrumentationTest (משויך ל-AJUR בצד המכשיר)
- GTest (בצד המכשיר ובצד המארח) עם ספריית googletest
- בדיקות שמנוהלות על ידי המארח (בדיקות Java שפועלות במארח ומשם קוראות למכשיר)
- בדיקות יחידה ב-Java טהור (ה-runner שלנו מבצע את שניהם)
- בדיקות Python
- בדיקות של Google Benchmark באמצעות ספריית benchmark
בנוסף למה שצוין למעלה, יש הרבה מריצים בהתאמה אישית לביצוע בדיקות. הם משמשים למטרות מיוחדות לבדיקות פונקציונליות מסוימות, כמו בדיקת אתחול.
כתיבת מפעיל בדיקות חדש
הנחיות נוספות לכתיבת מפעיל בדיקות חדש זמינות בקטע 'כתיבת בדיקות'.