सेल्फ़-इंस्ट्रूमेंटिंग टेस्ट के उदाहरण

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

इसका मतलब है कि कोई इंस्ट्रुमेंटेशन टेस्ट खुद को Android में इंजेक्ट नहीं कर सकता फ़्रेमवर्क, इसे सिस्टम सर्वर भी कहते हैं. Android को टेस्ट करने के लिए फ़्रेमवर्क के आधार पर, टेस्ट कोड सिर्फ़ सार्वजनिक एपीआई प्लैटफ़ॉर्म को शुरू कर सकता है या Android इंटरफ़ेस डेफ़िनिशन लैंग्वेज का इस्तेमाल करना एआईडीएल जो प्लैटफ़ॉर्म सोर्स ट्री में मौजूद है. टेस्ट की इस कैटगरी के लिए, किसी खास पैकेज को टारगेट करने का कोई मतलब नहीं है. इसलिए, यह इस तरह के इंस्ट्रुमेंटेशन, जिन्हें उसका खुद के टेस्ट ऐप्लिकेशन पैकेज टारगेट करने के लिए एलान किया जाना चाहिए, जैसे कि AndroidManifest.xml के अपने <manifest> टैग में तय किया गया है.

ज़रूरतों के आधार पर, इस कैटगरी में टेस्ट ऐप्लिकेशन पैकेज साथ ही:

• जांच के लिए बंडल गतिविधियां ज़रूरी हैं.
• सिस्टम के साथ यूज़र आईडी शेयर करें.
• प्लैटफ़ॉर्म पासकोड से साइन किया गया हो.
• उसे सार्वजनिक SDK टूल के बजाय, फ़्रेमवर्क सोर्स के हिसाब से कंपाइल किया जाना चाहिए.

इंस्ट्रूमेंटेशन टेस्ट की इस कैटगरी को कभी-कभी खुद से इंस्ट्रूमेंटेशन भी कहा जाता है. यहां सेल्फ़-इंस्ट्रुमेंटेशन टेस्ट के कुछ उदाहरण दिए गए हैं, प्लैटफ़ॉर्म का सोर्स:

• फ़्रेमवर्क/बेस/कोर/टेस्ट/
• फ़्रेमवर्क/बेस/सेवाएं/टेस्ट/सेवाओं की जांच

यहां दिया गया उदाहरण टारगेट के साथ एक नया इंस्ट्रुमेंटेशन टेस्ट लिख रहा है. अपने खुद के टेस्ट ऐप्लिकेशन पैकेज पर सेट किया गया है. इस गाइड में इनका इस्तेमाल किया जाता है की जांच करें:

• Hello World इंस्ट्रूमेंटेशन टेस्ट

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

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

आम तौर पर, आपकी टीम के पास पहले से ही कोड की जांच करने और टेस्ट जोड़ने के लिए, जगहों का एक पैटर्न होगा. ज़्यादातर टीमों के पास एक git रिपॉज़िटरी होता है या एक को अन्य टीम के साथ शेयर करते हैं, लेकिन एक खास सब-डायरेक्ट्री होती है जिसमें कॉम्पोनेंट का सोर्स कोड डालें.

यह मानते हुए कि आपके कॉम्पोनेंट सोर्स की रूट लोकेशन <component source root> है, ज़्यादातर कॉम्पोनेंट के तहत src और tests फ़ोल्डर होते हैं. साथ ही, कुछ कॉम्पोनेंट अतिरिक्त फ़ाइलें, जैसे कि Android.mk (या अतिरिक्त .mk फ़ाइलों में बांटा गया हो), मेनिफ़ेस्ट फ़ाइल AndroidManifest.xml और टेस्ट कॉन्फ़िगरेशन फ़ाइल 'AndroidTest.xml'.

आप एक बिलकुल नया टेस्ट जोड़ रहे हैं, इसलिए शायद आपको tests डायरेक्ट्री को जोड़ें, जो आपके कॉम्पोनेंट src के बगल में मौजूद होगा और इसे कॉन्टेंट से भर देगा.

कुछ मामलों में, आपकी टीम के पास tests के तहत और डायरेक्ट्री स्ट्रक्चर हो सकते हैं. ऐसा इसलिए होता है, क्योंकि टेस्ट के अलग-अलग सुइट को अलग-अलग APK में पैकेज करने की ज़रूरत होती है. और ऐसी स्थिति में, आपको tests में एक नई सब डायरेक्ट्री बनानी होगी.

भले ही, स्ट्रक्चर कुछ भी हो, आपको tests डायरेक्ट्री या बनाई गई नई सब-डायरेक्ट्री में, उन फ़ाइलों को भरना होगा जो सैंपल gerrit बदलाव में instrumentation डायरेक्ट्री में मौजूद हैं. इस दस्तावेज़ में, हर फ़ाइल के बारे में जानकारी दी गई है.

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

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

अगर आपको AndroidManifest.xml फ़ाइल के बारे में नहीं पता है, तो इसे देखें ऐप्लिकेशन मेनिफ़ेस्ट की खास जानकारी

यहां AndroidManifest.xml फ़ाइल का सैंपल दिया गया है:

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

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

    <instrumentation android:name="androidx.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 एट्रिब्यूट, ऐप्लिकेशन के पैकेज का नाम है: यह यूनीक आइडेंटिफ़ायर जिसका इस्तेमाल करके, Android ऐप्लिकेशन फ़्रेमवर्क आवेदन (या इस संदर्भ में: आपका टेस्ट ऐप्लिकेशन). सिस्टम में मौजूद हर उपयोगकर्ता उस पैकेज नाम से केवल एक ऐप्लिकेशन इंस्टॉल कर सकता है.

इसके अलावा, यह package एट्रिब्यूट वही है जो ComponentName#getPackageName() वापस किया जा सकता है. साथ ही, इसे आप अलग-अलग pm सब-प्रॉपर्टी से इंटरैक्ट करने के लिए इस्तेमाल कर सकते हैं कमांड adb shell का इस्तेमाल करते हैं.

ध्यान रखें कि आम तौर पर पैकेज का नाम एक ही स्टाइल में होता है का इस्तेमाल कर रहा है, तो असल में इसके साथ बहुत कम काम हैं. अन्य शब्दों के लिए, आपके ऐप्लिकेशन (या परीक्षण) पैकेज में किसी भी पैकेज वाली क्लास शामिल हो सकती हैं वहीं दूसरी तरफ़, नाम देने के लिए, आसान और आसान फ़ॉर्मैट इस्तेमाल किए जा सकते हैं. आपके ऐप्लिकेशन में स्तर का Java पैकेज नाम या ऐप्लिकेशन के समान परीक्षण पैकेज का नाम.

android:sharedUserId="android.uid.system"

इससे पता चलता है कि इंस्टॉलेशन के समय, इस APK फ़ाइल को वही यूज़र आईडी, यानी रनटाइम आइडेंटिटी दी जानी चाहिए जो मुख्य प्लैटफ़ॉर्म को दी गई है. ध्यान दें कि यह इस बात पर निर्भर करता है कि APK को उसी सर्टिफ़िकेट से साइन किया गया है जिससे कोर प्लैटफ़ॉर्म (पिछले सेक्शन में LOCAL_CERTIFICATE देखें) को साइन किया गया है. हालांकि, ये दोनों अलग-अलग कॉन्सेप्ट हैं:

• कुछ अनुमतियां या एपीआई, हस्ताक्षर की मदद से सुरक्षित होते हैं. इनके लिए, हस्ताक्षर करने वाले एक ही सर्टिफ़िकेट की ज़रूरत होती है
• कुछ अनुमतियों या एपीआई के लिए, कॉलर की system उपयोगकर्ता पहचान ज़रूरी होती है जिसे system के साथ यूज़र आईडी शेयर करने के लिए कॉलिंग पैकेज की ज़रूरत होती है, अगर यह पैकेज को कोर प्लैटफ़ॉर्म से अलग करना

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

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

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

आपने शायद देखा होगा कि यहां दिए गए targetPackage को इस फ़ाइल के manifest टैग में package एट्रिब्यूट का एलान किया गया है. जैसा कि इसमें बताया गया है टेस्टिंग की बुनियादी बातें, इंस्ट्रुमेंटेशन टेस्ट की इस कैटगरी में आम तौर पर, फ़्रेमवर्क एपीआई की जांच करने के लिए तय किया जाता है. इसलिए, एक खास टारगेट किए गए ऐप्लिकेशन पैकेज के लिए हो, दूसरी तरह से.

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

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

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

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

टेस्ट कॉन्फ़िगरेशन, डिवाइस सेटअप के खास विकल्प और डिफ़ॉल्ट सेटिंग तय कर सकता है आर्ग्युमेंट का इस्तेमाल करें. यहां उदाहरण देखें /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 के तरीकों पर किया जाता है, ताकि टेस्ट सेटअप करने से पहले और टेस्ट खत्म होने के बाद, teardown की प्रोसेस को पूरा किया जा सके. इसी तरह, @BeforeClass और इससे पहले सेटअप करने के लिए, JUnit4 के तरीकों में @AfterClass एनोटेशन इस्तेमाल किए जाते हैं सभी टेस्ट को टेस्ट करता है और उसके बाद डेटा हटा देता है. ध्यान दें कि क्लास-स्कोप सेटअप और टियरडाउन के तरीके स्टैटिक होने चाहिए. जांच के तरीकों की बात करें, तो JUnit के पुराने वर्शन के मुकाबले, अब उन्हें तरीके का नाम शुरू करने की ज़रूरत नहीं होती इसके बजाय, test के साथ हर एक एनोटेशन के लिए @Test का इस्तेमाल करना ज़रूरी है. हमेशा की तरह, जांच के तरीके सार्वजनिक होने चाहिए, किसी रिटर्न वैल्यू का एलान नहीं किया जाना चाहिए, कोई पैरामीटर नहीं होना चाहिए, और अपवाद भी हो सकते हैं.

इंस्ट्रूमेंटेशन क्लास का ऐक्सेस

हालांकि, यह नमस्ते दुनिया के बुनियादी उदाहरण में शामिल नहीं है, लेकिन यह Android टेस्ट, जिसमें Instrumentation इंस्टेंस को ऐक्सेस करने की ज़रूरत है: यह कोर एपीआई है ऐसा इंटरफ़ेस जो ऐप्लिकेशन के कॉन्टेक्स्ट और गतिविधि की लाइफ़साइकल का ऐक्सेस देता है मिलते-जुलते टेस्ट एपीआई वगैरह.

JUnit4 टेस्ट के लिए अब सामान्य बेस क्लास की ज़रूरत नहीं है. इसलिए, अब InstrumentationTestCase#getInstrumentation() के ज़रिए Instrumentation इंस्टेंस पाने की ज़रूरत नहीं है. इसके बजाय, नया टेस्ट रननर इसे InstrumentationRegistry के ज़रिए मैनेज करता है. यहां इंस्ट्रूमेंटेशन फ़्रेमवर्क से बनाए गए कॉन्टेक्स्ट और एनवायरमेंट सेटअप को सेव किया जाता है.

Instrumentation क्लास के इंस्टेंस को ऐक्सेस करने के लिए, बस स्टैटिक तरीके को कॉल करें InstrumentationRegistry क्लास के लिए getInstrumentation():

Instrumentation instrumentation = InstrumentationRegistry.getInstrumentation()

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

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

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