כתיבת בדיקה המבוססת על מארח ב-Commerce Federation

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

חשוב לזכור שאנחנו מתייחסים ל'צד המארח' ובדיקות "מבוססות-מארחים" לבדיקות רפואיות מסוימות שונה:

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

למה כדאי ליצור בדיקה שמבוססת על מארח ולא בדיקת אינסטרומנטציה?

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

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

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

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

מספקים גם גישה לאובייקט המכשיר הנטען ב-Trends:

  • 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 מאפשר להשתמש במכשיר ובמאפייני החנות שיכולים להיות בהיקף הסטטי או לא סטטי. BaseHostJUnit4Test תומך מקבלים את TestInformation בהיקף לא סטטי דרך #getTestInformation().

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

כיצד להגדיר בדיקה המבוססת על מארח ב-Trended?

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

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