ऐप्लिकेशन को टारगेट करने का उदाहरण

इंस्ट्रुमेंटेशन टेस्ट की यह कैटगरी, टारगेटिंग (विज्ञापन के लिए सही दर्शक चुनना) से अलग नहीं है सामान्य Android ऐप्लिकेशन इस्तेमाल करने लगते हैं. यह ध्यान देने वाली बात है कि जांच के लिए लागू जिनमें इंस्ट्रुमेंटेशन शामिल है, उस पर उसी प्रमाणपत्र के साथ हस्ताक्षर करने की आवश्यकता है को भी टारगेट करता है.

ध्यान दें कि इस गाइड में यह माना गया है कि आपको प्लैटफ़ॉर्म के सोर्स ट्री वर्कफ़्लो के बारे में पहले से कुछ जानकारी है. अगर ऐसा नहीं है, तो कृपया ज़रूरी शर्तें देखें. यहां दिया गया उदाहरण, टारगेट के साथ एक नया इंस्ट्रुमेंटेशन टेस्ट लिख रहा है अपने खुद के टेस्ट ऐप्लिकेशन पैकेज पर सेट किया गया है. अगर आपको इसके बारे में जानकारी नहीं है कॉन्सेप्ट को समझने के लिए, कृपया प्लैटफ़ॉर्म टेस्टिंग का परिचय पढ़ें.

यह गाइड, सैंपल के तौर पर यहां दिए गए टेस्ट का इस्तेमाल करती है:

• फ़्रेमवर्क/बेस/पैकेज/शेल/टेस्ट

मोटा इंप्रेशन पाने के लिए पहले कोड को ब्राउज़ करने का सुझाव दिया जाता है आगे बढ़ने से पहले.

सोर्स की जगह तय करें

क्योंकि इंस्ट्रुमेंटेशन टेस्ट किसी ऐप्लिकेशन को टारगेट करेगा, इसलिए कंवेंशन टेस्ट सोर्स कोड को tests डायरेक्ट्री में प्लैटफ़ॉर्म सोर्स ट्री में कॉम्पोनेंट की सोर्स डायरेक्ट्री शामिल करें.

शुरू से अंत तक के उदाहरण में, स्रोत की जगह के बारे में ज़्यादा चर्चाएं देखें सेल्फ़-इंस्ट्रूमेंटिंग टेस्ट.

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

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

आगे बढ़ने से पहले, हमारा सुझाव है कि आप ऐप्लिकेशन मेनिफ़ेस्ट की खास जानकारी चुनें.

इससे मेनिफ़ेस्ट फ़ाइल के बुनियादी कॉम्पोनेंट और उनके सुविधाओं के बारे में बात करेंगे.

मैन्युअल तरीके में किए गए बदलाव के सैंपल के लिए, मेनिफ़ेस्ट फ़ाइल के सबसे नए वर्शन को ऐक्सेस किया जा सकता है यहां: 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 पैकेज नाम या ऐप्लिकेशन के समान परीक्षण पैकेज का नाम.

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

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

android:targetPackage="com.android.shell"

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

आसान कॉन्फ़िगरेशन फ़ाइल

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

जटिल कॉन्फ़िगरेशन फ़ाइल

ज़्यादा मुश्किल टेस्ट के लिए, आपको टेस्ट कॉन्फ़िगरेशन भी लिखना होगा फ़ाइल को Android के टेस्ट हार्नेस, Trade Feफ़ेडरेशन के लिए सबमिट किया.

टेस्ट कॉन्फ़िगरेशन, डिवाइस सेटअप के खास विकल्प और डिफ़ॉल्ट सेटिंग तय कर सकता है आर्ग्युमेंट का इस्तेमाल करें.

जनरेट किए गए डेटा के सैंपल के लिए, कॉन्फ़िगरेशन फ़ाइल के सबसे नए वर्शन को ऐक्सेस किया जा सकता है यहां: 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>

यह ट्रेड फ़ेडरेशन को टारगेट पर 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 लाइब्रेरी को टेस्ट रनर के तौर पर इस्तेमाल करने से, नई JUnit4 स्टाइल की टेस्ट क्लास को अपनाया जा सकता है. साथ ही, सैंपल 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 एनोटेशन में पूरी टेस्ट क्लास के लिए, एक टेस्ट साइज़ बताया गया है: सभी इस टेस्ट क्लास में जोड़े गए टेस्ट के तरीके, इस टेस्ट साइज़ एनोटेशन को इनहेरिट करते हैं. प्री-टेस्ट क्लास सेटअप, टेस्ट के बाद टियर डाउन, और पोस्ट टेस्ट क्लास को हटाना: यह JUnit4 में, setUp और tearDown तरीकों से मिलता-जुलता है. Test एनोटेशन का इस्तेमाल, असल टेस्ट की जानकारी देने के लिए किया जाता है.

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

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

JUnit के पुराने वर्शन के उलट, टेस्ट के तरीकों के लिए अब इनकी ज़रूरत नहीं होती तरीके का नाम test से शुरू करने के लिए, इसके बजाय हर एक के साथ एनोटेट किया जाना चाहिए @Test के साथ. हमेशा की तरह, जांच के तरीके सार्वजनिक होने चाहिए, उनमें कोई रिटर्न वैल्यू नहीं होनी चाहिए, कोई पैरामीटर नहीं लेता, और अपवाद भी हो सकता है.

        Context context = InstrumentationRegistry.getTargetContext();

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

• getInstrumentation(): Instrumentation क्लास का इंस्टेंस
• getArguments(): कमांड लाइन आर्ग्युमेंट, इसके ज़रिए am instrument को पास किए गए -e <key> <value>

ऐप्लिकेशन को स्थानीय तौर पर बनाएं और टेस्ट करें

आम तौर पर इस्तेमाल किए जाने वाले उदाहरणों के लिए, यहां दिए गए तरीके अपनाएं एटेस्ट.

जिन मामलों में ज़्यादा कस्टमाइज़ करने की ज़रूरत होती है उनके लिए, नीचे दिए गए निर्देशों का पालन करें इंस्ट्रुमेंटेशन से जुड़े निर्देश शामिल करें.