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

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

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

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

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

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

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

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

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

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

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

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

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

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

ملف البيان

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

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

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

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

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

    <uses-sdk android:minSdkVersion="21" android:targetSdkVersion="21" />

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

    <instrumentation android:name="android.support.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 السمة هو اسم الحزمة التطبيق: هذا هو المعرف الفريد الذي يستخدمه إطار تطبيق الروبوت لتحديد تطبيق (أو في هذا السياق: تطبيق الاختبار). يمكن لكل مستخدم في النظام تثبيت تطبيق واحد فقط باسم الحزمة هذا.

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

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

android:sharedUserId="android.uid.system"

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

  • بعض الأذونات أو واجهات برمجة التطبيقات محمية بالتوقيع ، الأمر الذي يتطلب نفس شهادة التوقيع
  • بعض الأذونات أو واجهات برمجة التطبيقات تتطلب system هوية المستخدم المتصل، الأمر الذي يتطلب حزمة داعيا إلى حصة هوية المستخدم مع system ، اذا كان حزمة منفصلة من المنصة الأساسية نفسها
<uses-library android:name="android.test.runner" />

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

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

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

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

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

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

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

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

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

ميزات JUnit4

باستخدام android-support-test مكتبة كما عداء اختبار يمكن اعتماد فئات جديدة اختبار أسلوب JUnit4، وتغيير جيريت عينة يتضمن استخدام بعض أساسية جدا من معالمه. راجع المثال في /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() {
    ...

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

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

الوصول إلى instrumentation

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

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

للوصول إلى مثيل Instrumentation الطبقة، مجرد دعوة ساكنة طريقة getInstrumentation() على InstrumentationRegistry الفئة:

Instrumentation instrumentation = InstrumentationRegistry.getInstrumentation()

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

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

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