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

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

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

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

• أُطر العمل/base/الحزم/Shell/tests

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

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

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

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

ملف البيان

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

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

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

يمكن الوصول إلى أحدث إصدار من ملف البيان لنموذج تغيير Grit at: 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" />

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

android:targetPackage="com.android.shell"

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

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

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

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

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

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

يمكن الوصول إلى أحدث إصدار من ملف الإعداد لنموذج تغيير Grit at: 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 محدّد. هناك العديد من المُعِدين المستهدفين المتاحة للمطورين في الاتحاد التجاري ويمكن استخدامها لضمان إعداد الجهاز بشكل صحيح قبل تنفيذ الاختبار.

<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 كمشغِّل اختبارات إمكانية استخدام klassen اختبار جديدة بأسلوب JUnit4، ويحتوي نموذج تغيير gerrit على بعض الاستخدامات الأساسية جدًا لميزاته.

يمكن الوصول إلى أحدث رمز مصدر لعينة تغيير Grit على: frameworks/base/packages/Shell/tests/src/com/android/shell/BugreportReceiverTest.java

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

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

هناك اختلاف كبير في JUnit4، وهو أن الاختبارات لم تعد مطلوبة أن تكتسب من فئة اختبار أساسية مشتركة وإنما تكتب الاختبارات بلغة Java عادية الفئات واستخدام التعليق التوضيحي للإشارة إلى بعض إعدادات الاختبار والقيود. ضِمن هذا المثال، نطلب أن يتم تشغيل هذه الفئة باعتبارها نظام اختبار 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>

إنشاء التطبيقات واختبارها محليًا

وبالنسبة إلى حالات الاستخدام الأكثر شيوعًا، استخدم تأكيد:

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