توضّح هذه الصفحة كيفية كتابة اختبار جهاز بنمط 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@AfterClass-
Assume، 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>