توضّح هذه الصفحة كيفية كتابة اختبار جهاز على غرار 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()
: تعرِض هذه الدالة عنصر جهاز TF للتلاعب بالجهاز.getBuild()
: تعرِض هذه الدالة كائن TF لمعلومات الإصدار للحصول على معلومات عن الإصدار.getAbi()
: عرض معرّف ABI الذي يتم تشغيل الاختبار عليه
الدعم المتبادل: إعداد الأجهزة وتنظيفها حسب الفئة
لا ينطبق @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 الذي تريد تبادله، يتم إجراء الاختبارات المستندة إلى المضيف من خلال برنامج تشغيل HostTest.
<test class="com.android.tradefed.testtype.HostTest" >
<option name="class" value="android.sample.cts.SampleHostJUnit4DeviceTest" />
</test>