כתיבת בדיקה מבוססת-מארח ב-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());
    }
}

בדיקות שמופעלות על ידי המארח ב-Trade Federation מופעלות על ידי DeviceJUnit4ClassRunner, שהוא רכיב להרצת בדיקות JUnit4. המבנה הכללי של מחלקת הבדיקה זהה למבנה של בדיקת 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 של פרטי גרסה כדי לקבל מידע על הגרסה.
  • ‫getAbi(): מחזירה את ה-ABI שהבדיקה פועלת מולו.

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

ההערות JUnit4‏ @BeforeClass ו-@AfterClass רלוונטיות רק למתודות סטטיות, ולכן אי אפשר להשתמש ב-handler‏ #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 מאפשרת לכם להשתמש במכשיר ובמאפייני האחסון שאפשר להשתמש בהם בהיקף סטטי או לא סטטי. ‫BaseHostJUnit4Test תומך בקבלת TestInformation בהיקף שאינו סטטי באמצעות #getTestInformation().

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

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

בקובץ ההגדרות של Tradefed XML, בדיקות שמבוססות על המארח מופעלות באמצעות הרכיב HostTest.

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