בדף הזה מוסבר איך לכתוב בדיקת מכשיר בסגנון 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());
}
}
בדיקות מבוססות-מארח ב-Trends 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)
: הרצת בדיקת instrumentation במכשיר יעד באמצעות DeviceTestRunOptions כדי לטפל בכל האפשרויות האפשריות.
מספקים גם גישה לאובייקט המכשיר הנטען ב-Trends:
getDevice()
: מחזירה אובייקט של מכשיר TF לצורך מניפולציה על המכשיר.getBuild()
: הפונקציה מחזירה אובייקט TF של פרטי build כדי לקבל מידע על ה-build.getAbi()
: הפונקציה מחזירה את ה-ABI שבו הבדיקה פועלת.
תמיכה בשירותים מקצועיים: הכנה וניקוי של מכשירים לפי סיווג
JUnit4 @BeforeClass
ו-@AfterClass
רלוונטיים רק ל-methods סטטיות, ולכן אי אפשר להשתמש ב-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?
בקובץ התצורה של Tradefed בפורמט XML, בדיקות שמבוססות על המארח מופעלות באמצעות ה-runner HostTest.
<test class="com.android.tradefed.testtype.HostTest" >
<option name="class" value="android.sample.cts.SampleHostJUnit4DeviceTest" />
</test>