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

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

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

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

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

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

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

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

رؤية المزيد من المناقشات حول موقع المصدر في المثال من النهاية إلى النهاية لاختبارات instrumenting النفس .

ملف البيان

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

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

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

يمكن الوصول إلى أحدث إصدار من ملف البيان لنموذج تغيير gerrit على: https://android.googlesource.com/platform/frameworks/base/+/master/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 السمة هو اسم الحزمة التطبيق: هذا هو المعرف الفريد الذي يستخدمه إطار تطبيق الروبوت لتحديد تطبيق (أو في هذا السياق: تطبيق الاختبار). يمكن لكل مستخدم في النظام تثبيت تطبيق واحد فقط باسم الحزمة هذا.

لأن هذا هو حزمة تطبيق الاختبار، مستقلة عن حزمة التطبيق تحت الاختبار، يجب استخدام اسم حزمة مختلف: اتفاقية مشتركة واحدة هي إضافة لاحقة .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 كافيًا. انظر تكوين اختبار بسيط للحصول على التفاصيل.

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

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

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

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

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

ميزات JUnit4

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

يمكن الوصول إليها من أحدث الكود لتغيير جيريت عينة في: الأطر / القاعدة / الحزم / شل / الاختبارات / SRC / كوم / الروبوت / شل / 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 لأداء الإعداد قبل تنفيذ جميع الاختبارات في فئة الاختبار، وteardown بعد ذلك. لاحظ أن أساليب إعداد نطاق الفئة والتفكيك يجب أن تكون ثابتة.

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

        Context context = InstrumentationRegistry.getTargetContext();

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

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

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

لمعظم حالات الاستخدام المشترك، توظيف ATEST .

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