כתיבת בדיקה מבוססת-מארח ב-Trade Federation

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

חשוב לדעת שיש הבדל קל בין בדיקות 'בצד המארח' לבין בדיקות 'מונחות-מארח':

  • בדיקה מבוססת-מארח: בדיקה שפועלת במארח ומקיימת אינטראקציה עם מכשיר אחד או יותר. המערכת שנבדקת (SUT) לא נמצאת במארח עצמו, אלא נבדקת מהמארח.
  • בדיקה בצד המארח: בדיקה שפועלת רק במארח ובודקת משהו רק במארח, למשל בדיקות יחידה.

למה כדאי ליצור בדיקה מבוססת-מארח במקום בדיקת מכשור?

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

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

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

איך כותבים בדיקות מבוססות-מארח ב-TF?

הנה דוגמה:

@RunWith(DeviceJUnit4ClassRunner.class)
public class SampleHostJUnit4DeviceTest extends BaseHostJUnit4Test {
    @Before
    public void setUp() throws Exception {
       // Some setup
    }

    @Test
    public void testCheckWeHaveDevice() throws Exception {
        Assert.assertNotNull(getDevice());
    }
}

בדיקות שמנוהלות על ידי המארח באיחוד המסחר מופעלות על ידי מפעיל הבדיקות של JUnit4‏ DeviceJUnit4ClassRunner. המבנה הכללי של כיתה הבדיקה זהה למבנה של בדיקת JUnit4 רגילה:

  • @BeforeClass
  • @Before
  • @Test
  • @After
  • @AfterClass
  • Assume, Assert

הרחבת BaseHostJunit4Test היא דרך לקבל בירושה ממשקי API שימושיים של כלי בדיקה, כמו:

  • installPackage: מאפשרת להתקין קובץ APK במכשיר היעד.
  • installPackageAsUser: מאפשרת להתקין קובץ APK בתור משתמש במכשיר היעד.
  • uninstallPackage: מאפשרת להסיר התקנה של קובץ APK.
  • isPackageInstalled: בדיקה אם החבילה מותקנת.
  • hasDeviceFeature: בדיקה אם המכשיר תומך בתכונה מסוימת. (pm list features)
  • runDeviceTests(DeviceTestRunOptions options): מריצים בדיקת מכשור במכשיר יעד באמצעות DeviceTestRunOptions כדי לטפל בכל האפשרויות האפשריות.

צריך גם לספק גישה לאובייקט המכשיר ב-Tradefed:

  • getDevice(): הפונקציה מחזירה אובייקט של מכשיר TF לצורך מניפולציה במכשיר.
  • getBuild(): הפונקציה מחזירה אובייקט TF של פרטי build כדי לקבל מידע על ה-build.
  • getAbi(): הפונקציה מחזירה את ה-ABI שבו הבדיקה פועלת.

תמיכה ב-Tradefed: הכנה וסגירה של מכשירים לפי כיתה

@BeforeClass ו-@AfterClass ב-JUnit4 רלוונטיים רק לשיטות סטטיות, ולכן אי אפשר להשתמש במטפל #getDevice() כדי לבצע פעולות הגדרה או ניקוי חד-פעמיות ספציפיות למכשיר לכל כיתה. כדי לפתור את הבעיה, צריך להשתמש בתיוג של Tradefed.

  • @BeforeClassWithInfo: פועלת לפני ההערות מסוג @BeforeClass
  • @AfterClassWithInfo: פועל אחרי ההערות מסוג @AfterClass
   @BeforeClassWithInfo
   public static void beforeClassWithDevice(TestInformation testInfo) {
       assertNotNull(testInfo.getDevice());
       testInfo.properties().put("mytest:test-prop", "test");
   }

   @AfterClassWithInfo
   public static void afterClassWithDevice(TestInformation testInfo) {
       assertNotNull(testInfo.getDevice());
       testInfo.properties().put("mytest:test-prop", "test");
   }

TestInformation מאפשר לכם להשתמש במכשיר ולאחסן מאפיינים שאפשר להשתמש בהם ברמת ה-scope הסטטית או ברמת ה-scope הלא סטטית. ב-BaseHostJUnit4Test יש תמיכה בקבלת TestInformation בהיקף לא סטטי דרך #getTestInformation().

אם לא מרחיב את BaseHostJUnit4Test, אפשר להטמיע את ITestInformationReceiver כדי לקבל את האובייקט TestInformation.

איך מגדירים בדיקה מבוססת-מארח ב-Tradefed?

בקובץ התצורה של Tradefed בפורמט XML, בדיקות שמבוססות על המארח מופעלות באמצעות ה-runner‏ HostTest.

<test class="com.android.tradefed.testtype.HostTest" >
    <option name="class" value="android.sample.cts.SampleHostJUnit4DeviceTest" />
</test>