مثال الاختبارات الذاتية

عند بدء اختبار الأجهزة ، يتم إعادة تشغيل الحزمة المستهدفة الخاصة به مع إدخال رمز الأجهزة والبدء في التنفيذ. أحد الاستثناءات هو أن الحزمة المستهدفة هنا لا يمكن أن تكون إطار عمل تطبيق Android نفسه ، أي حزمة android ، لأن القيام بذلك سيؤدي إلى موقف متناقض حيث يحتاج إطار عمل Android إلى إعادة التشغيل ، وهو ما يدعم وظائف النظام ، بما في ذلك الأجهزة بحد ذاتها.

هذا يعني أن اختبار الأجهزة لا يمكنه حقن نفسه في إطار عمل Android ، المعروف أيضًا باسم خادم النظام ، للتنفيذ. من أجل اختبار إطار عمل Android ، يمكن لرمز الاختبار استدعاء أسطح API العامة فقط ، أو تلك التي تم الكشف عنها عبر Android Interface Definition Language AIDL المتاح في شجرة مصدر النظام الأساسي. بالنسبة لهذه الفئة من الاختبارات ، ليس من المجدي استهداف أي حزمة معينة. لذلك ، من المعتاد أن يتم الإعلان عن مثل هذه الأجهزة لاستهداف حزمة تطبيق الاختبار الخاصة بها ، كما هو محدد في علامة <manifest> الخاصة بها في AndroidManifest.xml .

اعتمادًا على المتطلبات ، قد تقوم حزم تطبيق الاختبار في هذه الفئة أيضًا بما يلي:

• أنشطة الحزمة اللازمة للاختبار.
• مشاركة معرف المستخدم مع النظام.
• يتم التوقيع باستخدام مفتاح النظام الأساسي.
• يتم تجميعها مقابل مصدر إطار العمل بدلاً من SDK العام.

يشار إلى هذه الفئة من اختبارات الأجهزة أحيانًا باسم الأجهزة الذاتية. فيما يلي بعض الأمثلة على اختبارات الأجهزة الذاتية في مصدر النظام الأساسي:

• الأطر / القاعدة / الأساسية / الاختبارات /
• الأطر / القاعدة / الخدمات / الاختبارات / الخدمات

المثال المغطى هنا هو كتابة اختبار أجهزة جديد مع تعيين الحزمة المستهدفة في حزمة تطبيق الاختبار الخاصة بها. يستخدم هذا الدليل الاختبار التالي ليكون بمثابة مثال:

• مرحبا العالم اختبار الأجهزة

يوصى بتصفح الكود أولاً للحصول على انطباع تقريبي قبل المتابعة.

تحديد موقع المصدر

عادةً ما يكون لدى فريقك بالفعل نمط محدد من الأماكن لتسجيل الدخول ، وأماكن لإضافة الاختبارات. تمتلك معظم الفرق مستودع git واحدًا ، أو تشارك واحدًا مع فرق أخرى ولكن لديها دليل فرعي مخصص يحتوي على كود مصدر مكون.

بافتراض أن موقع الجذر لمصدر المكون الخاص بك موجود في <component source root> ، فإن معظم المكونات تحتوي على src tests المجلدات تحتها ، وبعض الملفات الإضافية مثل Android.mk (أو مقسمة إلى ملفات .mk إضافية) ، ملف البيان AndroidManifest.xml وملف التكوين الاختباري "AndroidTest.xml".

نظرًا لأنك تضيف اختبارًا جديدًا ، فربما تحتاج إلى إنشاء دليل tests بجوار المكون src الخاص بك ، وتعبئته بالمحتوى.

في بعض الحالات ، قد يكون لدى فريقك المزيد من هياكل الدليل تحت tests نظرًا للحاجة إلى حزم مجموعات مختلفة من الاختبارات في تطبيقات فردية. وفي هذه الحالة ، ستحتاج إلى إنشاء دليل فرعي جديد تحت tests .

بغض النظر عن الهيكل ، سينتهي بك الأمر بملء دليل tests أو الدليل الفرعي الذي تم إنشاؤه حديثًا بملفات مشابهة لما هو موجود في دليل instrumentation في تغيير gerrit النموذجي. ستوضح الأقسام أدناه بمزيد من التفاصيل عن كل ملف.

ملف البيان

تمامًا مثل أي تطبيق عادي ، تحتاج كل وحدة اختبار أجهزة إلى ملف بيان. إذا قمت بتسمية الملف باسم AndroidManifest.xml وقمت بتوفيره بجوار Android.mk لوحدة الاختبار الخاصة بك ، فسيتم تضمينه تلقائيًا بواسطة ملف makefile الأساسي BUILD_PACKAGE .

قبل المضي قدمًا ، يوصى بشدة بالاطلاع على نظرة عامة على App Manifest أولاً.

يقدم هذا نظرة عامة على المكونات الأساسية لملف البيان ووظائفها. انظر المثال على platform_testing / الاختبارات / example / Instrumentation / AndroidManifest.xml .

يتم تضمين لقطة هنا للراحة:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="android.test.example.helloworld" >

    <application/>

    <instrumentation android:name="androidx.test.runner.AndroidJUnitRunner"
                     android:targetPackage="android.test.example.helloworld"
                     android:label="Hello World Test"/>

</manifest>

بعض الملاحظات المختارة في ملف البيان:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="android.test.example.helloworld" >

سمة package هي اسم حزمة التطبيق: هذا هو المعرف الفريد الذي يستخدمه إطار عمل تطبيق Android لتحديد تطبيق (أو في هذا السياق: تطبيق الاختبار الخاص بك). يمكن لكل مستخدم في النظام تثبيت تطبيق واحد فقط باسم الحزمة هذا.

علاوة على ذلك ، فإن سمة package هذه هي نفسها التي ComponentName#getPackageName() ، وكذلك نفس السمة التي تستخدمها للتفاعل مع أوامر pm الفرعية المختلفة عبر adb shell .

يرجى أيضًا ملاحظة أنه على الرغم من أن اسم الحزمة عادةً ما يكون بنفس نمط اسم حزمة Java ، إلا أنه يحتوي في الواقع على أشياء قليلة جدًا للقيام بها. بمعنى آخر ، قد تحتوي حزمة التطبيق (أو الاختبار) على فئات بأي أسماء حزم ، ولكن من ناحية أخرى ، يمكنك اختيار البساطة والحصول على اسم حزمة Java ذي المستوى الأعلى في التطبيق الخاص بك أو اختبار مطابق لاسم حزمة التطبيق.

android:sharedUserId="android.uid.system"

يوضح هذا أنه في وقت التثبيت ، يجب منح ملف apk هذا نفس معرف المستخدم ، أي معرف وقت التشغيل ، باعتباره النظام الأساسي الأساسي. لاحظ أن هذا يعتمد على توقيع apk بنفس الشهادة مثل النظام الأساسي الأساسي (انظر LOCAL_CERTIFICATE في القسم أعلاه) ، ومع ذلك فهما مفاهيم مختلفة:

• بعض الأذونات أو واجهات برمجة التطبيقات محمية بالتوقيع ، الأمر الذي يتطلب نفس شهادة التوقيع
• تتطلب بعض الأذونات أو واجهات برمجة التطبيقات هوية مستخدم system للمتصل ، الأمر الذي يتطلب من حزمة الاستدعاء مشاركة معرف المستخدم مع system ، إذا كانت حزمة منفصلة عن النظام الأساسي الأساسي نفسه

<uses-library android:name="android.test.runner" />

هذا مطلوب لجميع اختبارات الأجهزة نظرًا لأن الفئات ذات الصلة يتم حزمها في ملف مكتبة جرة إطار عمل منفصل ، وبالتالي يتطلب إدخالات إضافية للمسار عند استدعاء حزمة الاختبار بواسطة إطار عمل التطبيق.

android:targetPackage="android.test.example.helloworld"

ربما لاحظت أنه تم الإعلان عن targetPackage هنا مثل سمة package المُعلنة في علامة manifest لهذا الملف. كما هو مذكور في اختبار الأساسيات ، فإن هذه الفئة من اختبار الأجهزة مصممة عادةً لاختبار واجهات برمجة التطبيقات لإطار العمل ، لذلك ليس من المفيد جدًا أن يكون لديهم حزمة تطبيق مستهدفة محددة ، بخلاف ذلك نفسه.

ملف تكوين بسيط

يجب أن تحتوي كل وحدة اختبار جديدة على ملف تكوين لتوجيه نظام الإنشاء ببيانات وصفية للوحدة وتبعيات وقت التجميع وتعليمات الحزم. في معظم الحالات ، يكون خيار ملف Blueprint المستند إلى Soong كافيًا. للحصول على التفاصيل ، راجع تكوين الاختبار البسيط .

ملف التكوين المعقد

بالنسبة لهذه الحالات الأكثر تعقيدًا ، تحتاج أيضًا إلى كتابة ملف تكوين اختبار لتسخير اختبار Android ، اتحاد التجارة .

يمكن أن يحدد تكوين الاختبار خيارات إعداد الجهاز الخاصة والوسيطات الافتراضية لتوفير فئة الاختبار. انظر المثال على /platform_testing/tests/example/instrumentation/AndroidTest.xml .

يتم تضمين لقطة هنا للراحة:

<configuration description="Runs sample instrumentation test.">
  <target_preparer class="com.android.tradefed.targetprep.TestFilePushSetup"/>
  <target_preparer class="com.android.tradefed.targetprep.TestAppInstallSetup">
    <option name="test-file-name" value="HelloWorldTests.apk"/>
  </target_preparer>
  <target_preparer class="com.android.tradefed.targetprep.PushFilePreparer"/>
  <target_preparer class="com.android.tradefed.targetprep.RunCommandTargetPreparer"/>
  <option name="test-suite-tag" value="apct"/>
  <option name="test-tag" value="SampleInstrumentationTest"/>

  <test class="com.android.tradefed.testtype.AndroidJUnitTest">
    <option name="package" value="android.test.example.helloworld"/>
    <option name="runner" value="android.support.test.runner.AndroidJUnitRunner"/>
  </test>
</configuration>

بعض الملاحظات المختارة في ملف تكوين الاختبار:

<target_preparer class="com.android.tradefed.targetprep.TestAppInstallSetup">
  <option name="test-file-name" value="HelloWorldTests.apk"/>
</target_preparer>

هذا يخبر الاتحاد التجاري بتثبيت HelloWorldTests.apk على الجهاز المستهدف باستخدام target_preparer المحددة. هناك العديد من مُعدي الأهداف المتاحة للمطورين في الاتحاد التجاري ويمكن استخدامها لضمان إعداد الجهاز بشكل صحيح قبل تنفيذ الاختبار.

<test class="com.android.tradefed.testtype.AndroidJUnitTest">
  <option name="package" value="android.test.example.helloworld"/>
  <option name="runner" value="android.support.test.runner.AndroidJUnitRunner"/>
</test>

يحدد هذا فئة اختبار الاتحاد التجاري لاستخدامه في تنفيذ الاختبار واجتياز الحزمة على الجهاز المراد تنفيذه وإطار عداء الاختبار وهو JUnit في هذه الحالة.

لمزيد من المعلومات ، راجع اختبار الوحدة النمطية Configs .

ميزات JUnit4

يتيح استخدام مكتبة android-support-test باعتبارها عداء اختبار اعتماد فئات اختبار نمط JUnit4 الجديدة ، ويحتوي تغيير نموذج gerrit بعض الاستخدامات الأساسية جدًا لميزاته. انظر المثال على /platform_testing/tests/example/instrumentation/src/android/test/example/helloworld/HelloWorldTest.java .

في حين أن أنماط الاختبار عادة ما تكون خاصة بالفرق المكونة ، إلا أن هناك بعض أنماط الاستخدام المفيدة بشكل عام.

@RunWith(JUnit4.class)
public class HelloWorldTest {

هناك اختلاف كبير في JUnit4 وهو أن الاختبارات لم تعد مطلوبة للوراثة من فئة اختبار أساسية مشتركة ؛ بدلاً من ذلك ، يمكنك كتابة الاختبارات في فئات Java العادية واستخدام التعليقات التوضيحية للإشارة إلى بعض إعدادات الاختبار والقيود. في هذا المثال ، نوجه تعليمات بضرورة تشغيل هذه الفئة كاختبار JUnit4.

    @BeforeClass
    public static void beforeClass() {
    ...
    @AfterClass
    public static void afterClass() {
    ...
    @Before
    public void before() {
    ...
    @After
    public void after() {
    ...
    @Test
    @SmallTest
    public void testHelloWorld() {
    ...

يتم استخدام التعليقات التوضيحية @After وAfter في الطرق بواسطة @Before لإجراء إعداد الاختبار المسبق وتفكيك الاختبار اللاحق. وبالمثل ، يتم استخدام التعليقات التوضيحية @BeforeClass و @AfterClass في الطرق بواسطة JUnit4 لإجراء الإعداد قبل تنفيذ جميع الاختبارات في فئة الاختبار ، ثم تفكيكها بعد ذلك. لاحظ أن أساليب إعداد نطاق الفئة والتفكيك يجب أن تكون ثابتة. بالنسبة لطرق الاختبار ، على عكس الإصدار السابق من JUnit ، لم تعد بحاجة إلى بدء اسم الطريقة test ، بدلاً من ذلك ، يجب إضافة تعليق توضيحي لكل منها باستخدام @Test . كالعادة ، يجب أن تكون طرق الاختبار عامة ، ولا تعلن عن أي قيمة مرتجعة ، ولا تأخذ أي معلمات ، وقد تطرح استثناءات.

هام : طرق الاختبار نفسها مشروحة @Test ؛ ولاحظ أنه لكي يتم تنفيذ الاختبارات عبر APCT ، يجب وضع تعليقات توضيحية عليها بأحجام الاختبار: مثال على الطريقة المشروحة testHelloWorld كـ @SmallTest . يمكن تطبيق التعليق التوضيحي في نطاق الطريقة أو نطاق الفئة.

الوصول إلى instrumentation

على الرغم من عدم تناوله في مثال عالم الترحيب الأساسي ، إلا أنه من الشائع جدًا أن يتطلب اختبار Android مثيل Instrumentation : هذه هي واجهة API الأساسية التي توفر الوصول إلى سياقات التطبيق ، وواجهات برمجة تطبيقات الاختبار ذات الصلة بدورة حياة النشاط والمزيد.

نظرًا لأن اختبارات JUnit4 لم تعد تتطلب فئة أساسية مشتركة ، فلم يعد من الضروري الحصول على مثيل Instrumentation عبر InstrumentationTestCase#getInstrumentation() ، بدلاً من ذلك ، يديرها عداء الاختبار الجديد عبر InstrumentationRegistry حيث يتم تخزين الإعداد السياقي والبيئي الذي تم إنشاؤه بواسطة إطار عمل الأجهزة.

للوصول إلى مثيل فئة Instrumentation ، ما عليك سوى استدعاء الأسلوب الثابت getInstrumentation() في فئة InstrumentationRegistry :

Instrumentation instrumentation = InstrumentationRegistry.getInstrumentation()

بناء واختبار محليًا

لحالات الاستخدام الأكثر شيوعًا ، استخدم Atest .

للحالات الأكثر تعقيدًا التي تتطلب تخصيصًا أكبر ، اتبع تعليمات الأجهزة .