כתוב מבחן מונע מארח בפדרציית המסחר

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

תמיכת Tradefed: הכנה וניקיון של מכשיר לפי מחלקה

JUnit4 @BeforeClass ו- @AfterClass ישימים רק לשיטות סטטיות, מה שלא מאפשר להשתמש במטפל #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>