توضّح هذه الصفحة كيفية كتابة اختبار جهاز بنمط 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 إلى أداة تنفيذ اختبار JUnit4، وهي DeviceJUnit4ClassRunner. البنية العامة لفئة الاختبار هي نفسها بنية اختبار JUnit4 العادي:
@BeforeClass@Before@Test@After@AfterClassAssume،Assert
يوفّر توسيع BaseHostJunit4Test طريقة لتضمين واجهة برمجة تطبيقات لأدوات اختبار مفيدة، مثل:
-
installPackage: تتيح تثبيت حزمة APK على جهاز الاختبار. -
installPackageAsUser: يسمح بتثبيت حزمة APK كمستخدم على الجهاز المستهدف. uninstallPackage: تتيح إلغاء تثبيت حِزمة APK.isPackageInstalled: للتحقّق ممّا إذا كانت الحزمة مثبَّتة أم لا.hasDeviceFeature: التحقّق مما إذا كان الجهاز يتيح استخدام ميزة معيّنة أم لا (pm list features)-
runDeviceTests(DeviceTestRunOptions options): شغِّل اختبار لقياس حالة التطبيق على جهاز الاختبار باستخدام DeviceTestRunOptions للتعامل مع جميع الخيارات المتاحة.
يجب أيضًا توفير إذن الوصول إلى عنصر جهاز Tradefed:
-
getDevice(): تعرض عنصر جهاز TensorFlow للتعامل مع الجهاز. getBuild(): تعرض عنصر TF يتضمّن معلومات الإصدار للحصول على معلومات حول الإصدار.-
getAbi(): تعرض واجهة التطبيق الثنائية التي يتم إجراء الاختبار عليها.
توافق Tradefed: إعداد الجهاز وتنظيفه لكل فئة
لا ينطبق @BeforeClass و@AfterClass في JUnit4 إلا على الطرق الثابتة،
ما يجعل من المستحيل استخدام معالج #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؟
في ملف إعداد XML الخاص بـ Tradefed، يتم تشغيل الاختبارات المستندة إلى المضيف من خلال أداة التشغيل HostTest.
<test class="com.android.tradefed.testtype.HostTest" >
<option name="class" value="android.sample.cts.SampleHostJUnit4DeviceTest" />
</test>