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

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

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

يستخدم هذا الدليل الاختبار التالي كمثال:

• ‫frameworks/base/packages/Shell/tests

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

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

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

يمكنك الاطّلاع على مزيد من المناقشات حول موقع المصدر في الـ مثال الشامل للاختبارات التي تقيس حالة التطبيق ذاتيًا.

ملف البيان

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

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

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

يمكنك الوصول إلى أحدث إصدار من ملف البيان لتغيير gerrit النموذجي على الرابط التالي: https://android.googlesource.com/platform/frameworks/base/+/android17-release/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" />

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

android:targetPackage="com.android.shell"

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

ملف إعداد بسيط

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

ملف إعداد معقّد

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

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

يمكنك الوصول إلى أحدث إصدار من ملف الإعداد لتغيير gerrit النموذجي على الرابط التالي: على: frameworks/base/packages/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>

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

<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>

يحدّد هذا الإعداد فئة اختبار Trade Federation التي سيتم استخدامها لتنفيذ الاختبار، ويُمرِّر الحزمة على الجهاز التي سيتم تنفيذها وإطار عمل أداة تشغيل الاختبار، وهو JUnit في هذه الحالة.

يمكنك الاطّلاع هنا على مزيد من المعلومات حول إعدادات نموذج الاختبار

ميزات JUnit4

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

يمكنك الوصول إلى أحدث رمز مصدر لتغيير gerrit النموذجي على الرابط التالي: frameworks/base/packages/Shell/tests/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() {
    ...

يستخدم JUnit4 الشرح التوضيحي @Before في الطرق لتنفيذ إعداد ما قبل الاختبار. على الرغم من عدم استخدام هذا الشرح التوضيحي في هذا المثال، يتوفّر أيضًا @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.

بالنسبة إلى الحالات الأكثر تعقيدًا التي تتطلب تخصيصًا أكبر، اتّبِع الـ تعليمات قياس حالة التطبيق.