استهداف تطبيق مثال

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

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

يستخدم هذا الدليل اختبار المتابعة ليكون بمثابة عينة:

  • الأطر / القاعدة / الحزم / شل / الاختبارات

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

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

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

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

ملف البيان

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

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

يقدم هذا نظرة عامة على المكونات الأساسية لملف البيان ووظائفها.

يمكن الوصول إلى أحدث إصدار من ملف البيان لنموذج تغيير gerrit على: https://android.googlesource.com/platform/frameworks/base/+/main/packages/Shell/tests/AndroidManifest.xml

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

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.android.shell.tests">

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

        <activity
            android:name="com.android.shell.ActionSendMultipleConsumerActivity"
            android:label="ActionSendMultipleConsumer"
            android:theme="@android:style/Theme.NoDisplay"
            android:noHistory="true"
            android:excludeFromRecents="true">
            <intent-filter>
                <action android:name="android.intent.action.SEND_MULTIPLE" />
                <category android:name="android.intent.category.DEFAULT" />
                <data android:mimeType="*/*" />
            </intent-filter>
        </activity>
    </application>

    <instrumentation android:name="android.support.test.runner.AndroidJUnitRunner"
        android:targetPackage="com.android.shell"
        android:label="Tests for Shell" />

</manifest>

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

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.android.shell.tests">

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

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

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

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

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

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

android:targetPackage="com.android.shell"

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

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

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

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

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

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

يمكن الوصول إلى أحدث إصدار من ملف التكوين لعينة تغيير gerrit على: framework / base /pack / Shell / tests / AndroidTest.xml

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

<configuration description="Runs Tests for Shell.">
    <target_preparer class="com.android.tradefed.targetprep.TestAppInstallSetup">
        <option name="test-file-name" value="ShellTests.apk" />
    </target_preparer>

    <option name="test-suite-tag" value="apct" />
    <option name="test-tag" value="ShellTests" />
    <test class="com.android.tradefed.testtype.AndroidJUnitTest" >
        <option name="package" value="com.android.shell.tests" />
        <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="ShellTests.apk"/>
</target_preparer>

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

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

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

انظر هنا لمزيد من المعلومات حول اختبار الوحدة النمطية Configs

ميزات JUnit4

يتيح استخدام مكتبة android-support-test باعتبارها عداء اختبار اعتماد فئات اختبار نمط JUnit4 الجديدة ، ويحتوي تغيير نموذج gerrit بعض الاستخدامات الأساسية جدًا لميزاته.

يمكن الوصول إلى أحدث كود مصدر لعينة تغيير gerrit على: أطر عمل / قاعدة / حزم / شيل / اختبارات / src / com / android / shell / BugreportReceiverTest.java

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

@SmallTest
@RunWith(AndroidJUnit4.class)
public final class FeatureFactoryImplTest {

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

حدد التعليق @SmallTest حجم اختبار لفئة الاختبار بأكملها: جميع طرق الاختبار المضافة إلى فئة الاختبار هذه ترث التعليق التوضيحي لحجم الاختبار هذا. إعداد فئة الاختبار المسبق ، وتمزيق الاختبار اللاحق ، وفصل فئة الاختبار اللاحق: على غرار أساليب setUp و tearDown في JUnit4. يستخدم شرح Test لتوضيح الاختبار الفعلي.

    @Before
    public void setup() {
    ...
    @Test
    public void testGetProvider_shouldCacheProvider() {
    ...

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

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

        Context context = InstrumentationRegistry.getTargetContext();

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

  • getInstrumentation() : المثيل لفئة Instrumentation
  • getArguments() : تم تمرير وسيطات سطر الأوامر إلى am instrument عبر -e <key> <value>

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

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

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