Google is committed to advancing racial equity for Black communities. See how.
इस पेज का अनुवाद Cloud Translation API से किया गया है.
Switch to English

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

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

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

आवश्यकताओं के आधार पर, इस श्रेणी में परीक्षण पैकेज पैकेज भी हो सकते हैं:

  • परीक्षण के लिए आवश्यक बंडल गतिविधियाँ।
  • सिस्टम के साथ उपयोगकर्ता आईडी साझा करें।
  • प्लेटफ़ॉर्म की के साथ हस्ताक्षर किए जाएं।
  • सार्वजनिक एसडीके के बजाय रूपरेखा स्रोत के खिलाफ संकलित करें।

इंस्ट्रूमेंटेशन परीक्षणों की इस श्रेणी को कभी-कभी स्व-इंस्ट्रूमेंटेशन कहा जाता है। प्लेटफ़ॉर्म स्रोत में स्व-इंस्ट्रूमेंटेशन परीक्षणों के कुछ उदाहरण इस प्रकार हैं:

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

आगे बढ़ने से पहले किसी न किसी छाप को प्राप्त करने के लिए पहले कोड के माध्यम से ब्राउज़ करने की सिफारिश की जाती है।

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

आमतौर पर आपकी टीम में पहले से ही कोड में जांच करने के लिए और परीक्षण जोड़ने के लिए स्थानों का एक स्थापित पैटर्न होगा। अधिकांश टीम एकल git रिपॉजिटरी का मालिक है, या अन्य टीमों के साथ एक साझा करता है, लेकिन एक समर्पित उप निर्देशिका है जिसमें घटक स्रोत कोड होता है।

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

जब से आप एक नया परीक्षण जोड़ रहे हैं, तो आपको संभवतः अपने घटक src बगल में tests निर्देशिका बनाने की आवश्यकता होगी, और इसे सामग्री के साथ आबाद करें।

कुछ मामलों में, आपकी टीम के पास अलग-अलग एप्कों में परीक्षणों के विभिन्न स्वीट्स पैकेज करने की आवश्यकता के कारण tests के तहत आगे की निर्देशिका संरचनाएं हो सकती हैं। और इस मामले में, आपको tests तहत एक नई उप निर्देशिका बनाने की आवश्यकता होगी।

संरचना की परवाह किए बिना, आप tests निर्देशिका या नई बनाई गई उप निर्देशिका को उसी तरह से फाइलों के साथ समाप्‍त करेंगे जो सैंपल गेरिट परिवर्तन में instrumentation डायरेक्टरी में है। नीचे दिए गए अनुभाग प्रत्येक फ़ाइल के आगे विवरण में बताएंगे।

प्रकट फ़ाइल

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

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

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

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

android:sharedUserId="android.uid.system"

यह घोषणा करता है कि स्थापना के समय, इस एपीके को मूल प्लेटफॉर्म के रूप में एक ही उपयोगकर्ता आईडी, यानी रनटाइम पहचान, दी जानी चाहिए। ध्यान दें कि यह कोर प्लेटफ़ॉर्म के समान प्रमाणपत्र के साथ साइन किए जा रहे LOCAL_CERTIFICATE पर निर्भर है (ऊपर अनुभाग में LOCAL_CERTIFICATE देखें), फिर भी वे विभिन्न अवधारणाएँ हैं:

  • कुछ अनुमतियाँ या API हस्ताक्षर सुरक्षित हैं, जिनके लिए समान हस्ताक्षर प्रमाणपत्र की आवश्यकता होती है
  • कुछ अनुमतियों या API को कॉलर की system उपयोगकर्ता पहचान की आवश्यकता होती है, जिसके लिए उपयोगकर्ता आईडी को system साथ साझा करने के लिए कॉलिंग पैकेज की आवश्यकता system , यदि यह कोर प्लेटफॉर्म से अलग पैकेज है
<uses-library android:name="android.test.runner" />

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

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

आपने देखा होगा कि यहाँ targetPackage को उसी तरह घोषित किया जाता है जैसे इस फ़ाइल के manifest टैग में package विशेषता को घोषित किया गया था। जैसा कि टेस्टिंग बेसिक्स में उल्लेख किया गया है, इंस्ट्रूमेंटेशन टेस्ट की यह श्रेणी आम तौर पर फ्रेमवर्क एपीआई की टेस्टिंग के लिए होती है, इसलिए उनके लिए एक विशिष्ट लक्षित एप्लिकेशन पैकेज, तब स्वयं ही बहुत सार्थक नहीं होता है।

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

प्रत्येक नए परीक्षण मॉड्यूल में मॉड्यूल मेटाडेटा, संकलन-समय निर्भरता और पैकेजिंग निर्देशों के साथ निर्माण प्रणाली को निर्देशित करने के लिए एक कॉन्फ़िगरेशन फ़ाइल होनी चाहिए। ज्यादातर मामलों में, 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>

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

<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 धावक के रूप में android-support-test लाइब्रेरी का उपयोग करना नए JUnit4 शैली परीक्षण कक्षाओं को अपनाने में सक्षम बनाता है, और नमूना गेरिट परिवर्तन में इसकी विशेषताओं का कुछ बहुत ही मूल उपयोग होता है। /Platform_testing/tests/example/instrumentation/src/android/test/example/helloworld/HelloWorldTest.java पर उदाहरण देखें।

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

@RunWith(JUnit4.class)
public class HelloWorldTest {

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

    @BeforeClass
    public static void beforeClass() {
    ...
    @AfterClass
    public static void afterClass() {
    ...
    @Before
    public void before() {
    ...
    @After
    public void after() {
    ...
    @Test
    @SmallTest
    public void testHelloWorld() {
    ...

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

महत्वपूर्ण : परीक्षण विधियों को स्वयं @Test टिप्पणी एनोटेशन के साथ एनोटेट किया @Test ; और ध्यान दें कि परीक्षण के लिए APCT के माध्यम से निष्पादित करने के लिए, वे परीक्षण आकार के साथ एनोटेट किया जाना चाहिए: उदाहरण एनोटेट विधि testHelloWorld रूप @SmallTest । एनोटेशन को विधि के दायरे, या वर्ग के दायरे में लागू किया जा सकता है।

एक्सेसिंग instrumentation

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

क्योंकि JUnit4 परीक्षणों को अब एक सामान्य आधार वर्ग की आवश्यकता नहीं है, इसलिए InstrumentationTestCase#getInstrumentation() माध्यम से Instrumentation इंस्टेंस प्राप्त करना आवश्यक नहीं है, इसके बजाय, नया टेस्ट रनर InstrumentationRegistry माध्यम से इसका प्रबंधन करता है। जहां इंस्ट्रूमेंटेशन फ्रेमवर्क द्वारा बनाई गई प्रासंगिक और पर्यावरणीय सेटअप संग्रहीत होती है।

के कहने पर पहुंचने के लिए Instrumentation वर्ग, बस स्थिर विधि कॉल getInstrumentation() पर InstrumentationRegistry वर्ग:

Instrumentation instrumentation = InstrumentationRegistry.getInstrumentation()

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

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

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