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

בדיקות מבוססות-מארח באיחוד סחר הסחר מבוצעות על ידי 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 של פרטי build כדי לקבל מידע על ה-build.
  • getAbi(): מחזירה את ה-ABI שמולו מתבצעת הבדיקה.

תמיכה בשימוש מקצועי: הכנה וניקיון של מכשירים לפי סיווג

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

  • @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?

בקובץ התצורה של XML בתחום ה-TrendFed, הבדיקות שמבוססות על המארח מבוצעות דרך בדיקת מארח משחק.

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