एक आवेदन उदाहरण को लक्षित करना

इंस्ट्रूमेंटेशन टेस्ट की यह श्रेणी नियमित एंड्रॉइड एप्लिकेशन को लक्षित करने वालों से अलग नहीं है। यह ध्यान देने योग्य है कि जिस परीक्षण आवेदन में उपकरण शामिल है, उस पर उसी प्रमाणपत्र के साथ हस्ताक्षर किए जाने की आवश्यकता है जिस एप्लिकेशन को वह लक्षित कर रहा है।

ध्यान दें कि यह मार्गदर्शिका मानती है कि आपको प्लेटफ़ॉर्म स्रोत ट्री वर्कफ़्लो में पहले से ही कुछ ज्ञान है। यदि नहीं, तो कृपया आवश्यकताएँ देखें। यहां कवर किया गया उदाहरण अपने स्वयं के परीक्षण एप्लिकेशन पैकेज पर लक्ष्य पैकेज सेट के साथ एक नया उपकरण परीक्षण लिख रहा है। यदि आप अवधारणा से अपरिचित हैं, तो कृपया प्लेटफ़ॉर्म परीक्षण परिचय पढ़ें।

यह मार्गदर्शिका नमूने के रूप में कार्य करने के लिए अनुवर्ती परीक्षण का उपयोग करती है:

  • चौखटे/आधार/पैकेज/शैल/परीक्षण

आगे बढ़ने से पहले एक मोटा प्रभाव प्राप्त करने के लिए पहले कोड को ब्राउज़ करने की अनुशंसा की जाती है।

स्रोत स्थान पर निर्णय लेना

क्योंकि इंस्ट्रूमेंटेशन टेस्ट एक एप्लिकेशन को लक्षित करेगा, कन्वेंशन टेस्ट सोर्स कोड को tests डायरेक्टरी में आपके कंपोनेंट सोर्स डायरेक्टरी के रूट के तहत प्लेटफॉर्म सोर्स ट्री में रखना है।

सेल्फ़-इंस्ट्रूमेंटिंग परीक्षणों के लिए एंड-टू-एंड उदाहरण में स्रोत स्थान के बारे में और चर्चाएँ देखें।

मेनिफेस्ट फ़ाइल

एक नियमित एप्लिकेशन की तरह, प्रत्येक इंस्ट्रूमेंटेशन टेस्ट मॉड्यूल को एक मेनिफेस्ट फ़ाइल की आवश्यकता होती है। यदि आप फ़ाइल को AndroidManifest.xml नाम देते हैं और इसे अपने परीक्षण मॉड्यूल के लिए Android.mk के बगल में प्रदान करते हैं, तो यह BUILD_PACKAGE कोर मेकफ़ाइल द्वारा स्वचालित रूप से शामिल हो जाएगा।

आगे बढ़ने से पहले, यह अनुशंसा की जाती है कि आप पहले ऐप मेनिफेस्ट अवलोकन देखें

यह एक मेनिफेस्ट फ़ाइल के बुनियादी घटकों और उनकी कार्यक्षमताओं का एक सिंहावलोकन देता है।

नमूना 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() रिटर्न करता है, और उसी का उपयोग आप adb shell के माध्यम से विभिन्न pm सब कमांड के साथ इंटरैक्ट करने के लिए भी करेंगे।

कृपया यह भी ध्यान दें कि हालांकि पैकेज का नाम आमतौर पर जावा पैकेज नाम के समान शैली में होता है, लेकिन वास्तव में इसके साथ बहुत कम चीजें होती हैं। दूसरे शब्दों में, आपके एप्लिकेशन (या परीक्षण) पैकेज में किसी भी पैकेज नाम के साथ कक्षाएं हो सकती हैं, हालांकि दूसरी ओर, आप सादगी का विकल्प चुन सकते हैं और अपने आवेदन में अपने शीर्ष स्तर के जावा पैकेज का नाम रख सकते हैं या एप्लिकेशन पैकेज नाम के समान परीक्षण कर सकते हैं।

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

यह सभी इंस्ट्रुमेंटेशन परीक्षणों के लिए आवश्यक है क्योंकि संबंधित वर्गों को एक अलग फ्रेमवर्क जार लाइब्रेरी फ़ाइल में पैक किया जाता है, इसलिए जब एप्लिकेशन फ्रेमवर्क द्वारा परीक्षण पैकेज लागू किया जाता है तो अतिरिक्त क्लासपाथ प्रविष्टियों की आवश्यकता होती है।

android:targetPackage="com.android.shell"

यह उपकरण के लक्ष्य पैकेज को com.android.shell पर सेट करता है। जब इंस्ट्रूमेंटेशन को एम am instrument कमांड के माध्यम से लागू किया जाता है, तो फ्रेमवर्क com.android.shell प्रक्रिया को पुनरारंभ करता है, और परीक्षण निष्पादन के लिए प्रक्रिया में इंस्ट्रूमेंटेशन कोड को इंजेक्ट करता है। इसका मतलब यह भी है कि परीक्षण कोड के पास परीक्षण के तहत आवेदन में चल रहे सभी वर्ग उदाहरणों तक पहुंच होगी और राज्य में हेरफेर करने में सक्षम हो सकता है जो परीक्षण हुक पर निर्भर करता है।

सरल विन्यास फाइल

प्रत्येक नए परीक्षण मॉड्यूल में मॉड्यूल मेटाडेटा, संकलन-समय निर्भरता और पैकेजिंग निर्देशों के साथ बिल्ड सिस्टम को निर्देशित करने के लिए एक कॉन्फ़िगरेशन फ़ाइल होनी चाहिए। ज्यादातर मामलों में, सूंग-आधारित, ब्लूप्रिंट फ़ाइल विकल्प पर्याप्त है। विवरण के लिए सरल परीक्षण विन्यास देखें।

जटिल विन्यास फाइल

अधिक जटिल परीक्षणों के लिए, आपको एंड्रॉइड के टेस्ट हार्नेस, ट्रेड फेडरेशन के लिए एक परीक्षण कॉन्फ़िगरेशन फ़ाइल भी लिखनी होगी।

परीक्षण कॉन्फ़िगरेशन परीक्षण वर्ग की आपूर्ति के लिए विशेष उपकरण सेटअप विकल्प और डिफ़ॉल्ट तर्क निर्दिष्ट कर सकता है।

नमूना 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>

यह ट्रेड फेडरेशन को एक निर्दिष्ट target_preparer का उपयोग करके लक्ष्य डिवाइस पर ShellTests.apk स्थापित करने के लिए कहता है। ट्रेड फेडरेशन में डेवलपर्स के लिए कई लक्ष्य तैयार करने वाले उपलब्ध हैं और इनका उपयोग यह सुनिश्चित करने के लिए किया जा सकता है कि परीक्षण निष्पादन से पहले डिवाइस को ठीक से सेटअप किया गया है।

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

यह ट्रेड फेडरेशन टेस्ट क्लास को परीक्षण को निष्पादित करने के लिए उपयोग करने के लिए निर्दिष्ट करता है और डिवाइस पर पैकेज में पास करता है और टेस्ट रनर फ्रेमवर्क जो इस मामले में जुनीट है।

टेस्ट मॉड्यूल कॉन्फिग के बारे में अधिक जानकारी के लिए यहां देखें

जुनीट4 विशेषताएं

परीक्षण रनर के रूप में android-support-test लाइब्रेरी का उपयोग करने से नई JUnit4 शैली परीक्षण कक्षाओं को अपनाने में मदद मिलती है, और नमूना gerrit परिवर्तन में इसकी विशेषताओं का कुछ बहुत ही बुनियादी उपयोग होता है।

नमूना गेरिट परिवर्तन के लिए नवीनतम स्रोत कोड तक पहुँचा जा सकता है: चौखटे/आधार/पैकेज/शैल/परीक्षण/src/com/android/shell/BugreportReceiverTest.java

जबकि परीक्षण पैटर्न आमतौर पर घटक टीमों के लिए विशिष्ट होते हैं, कुछ आम तौर पर उपयोगी उपयोग पैटर्न होते हैं।

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

JUnit4 में एक महत्वपूर्ण अंतर यह है कि एक सामान्य बेस टेस्ट क्लास से इनहेरिट करने के लिए अब परीक्षणों की आवश्यकता नहीं है; इसके बजाय, आप सादे जावा कक्षाओं में परीक्षण लिखते हैं और कुछ परीक्षण सेटअप और बाधाओं को इंगित करने के लिए एनोटेशन का उपयोग करते हैं। इस उदाहरण में, हम निर्देश दे रहे हैं कि इस वर्ग को Android JUnit4 परीक्षण के रूप में चलाया जाना चाहिए।

@SmallTest एनोटेशन ने संपूर्ण परीक्षण वर्ग के लिए एक परीक्षण आकार निर्दिष्ट किया है: इस परीक्षण वर्ग में जोड़े गए सभी परीक्षण विधियाँ इस परीक्षण आकार एनोटेशन को इनहेरिट करती हैं। प्री टेस्ट क्लास सेटअप, पोस्ट टेस्ट टियर डाउन, और पोस्ट टेस्ट क्लास टियर डाउन: JUnit4 में setUp और tearDown विधियों के समान। वास्तविक परीक्षण की व्याख्या करने के लिए Test एनोटेशन का उपयोग किया जाता है।

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

पूर्व परीक्षण सेटअप करने के लिए JUnit4 द्वारा विधियों पर @Before एनोटेशन का उपयोग किया जाता है। हालांकि इस उदाहरण में उपयोग नहीं किया गया है, पोस्ट टेस्ट टियरडाउन के लिए @After भी है। इसी तरह, @BeforeClass और @AfterClass एनोटेशन का उपयोग परीक्षण वर्ग में सभी परीक्षणों को निष्पादित करने से पहले सेटअप करने के लिए JUnit4 द्वारा विधियों पर किया जा सकता है, और बाद में टियरडाउन किया जा सकता है। ध्यान दें कि क्लास-स्कोप सेटअप और टियरडाउन विधियाँ स्थिर होनी चाहिए।

परीक्षण विधियों के लिए, जुनीट के पुराने संस्करण के विपरीत, उन्हें अब test के साथ विधि नाम शुरू करने की आवश्यकता नहीं है, इसके बजाय, उनमें से प्रत्येक को @Test के साथ एनोटेट किया जाना चाहिए। हमेशा की तरह, परीक्षण विधियों को सार्वजनिक होना चाहिए, कोई वापसी मूल्य घोषित नहीं करना चाहिए, कोई पैरामीटर नहीं लेना चाहिए, और अपवाद फेंक सकते हैं।

        Context context = InstrumentationRegistry.getTargetContext();

चूंकि JUnit4 परीक्षणों को अब एक सामान्य आधार वर्ग की आवश्यकता नहीं है, इसलिए अब बेस क्लास विधियों के माध्यम से getContext() या getTargetContext() के माध्यम से Context उदाहरण प्राप्त करना आवश्यक नहीं है; इसके बजाय, नया टेस्ट रनर उन्हें InstrumentationRegistry रजिस्ट्री के माध्यम से प्रबंधित करता है जहां इंस्ट्रुमेंटेशन फ्रेमवर्क द्वारा बनाए गए प्रासंगिक और पर्यावरणीय सेटअप को संग्रहीत किया जाता है। इस कक्षा के माध्यम से, आप यह भी कॉल कर सकते हैं:

  • getInstrumentation() : Instrumentation क्लास का उदाहरण
  • getArguments() : कमांड लाइन तर्क -e <key> <value> के माध्यम से am instrument

स्थानीय रूप से निर्माण और परीक्षण करें

सबसे आम उपयोग के मामलों के लिए, Atest को नियोजित करें।

अधिक जटिल मामलों के लिए अधिक अनुकूलन की आवश्यकता होती है, इंस्ट्रूमेंटेशन निर्देशों का पालन करें।