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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

यह मेनिफेस्ट फ़ाइल के मूल घटकों और उनकी कार्यात्मकताओं का अवलोकन देता है। उदाहरण को platform_testing/tests/example/instrumentation/AndroidManifest.xml पर देखें।

सुविधा के लिए यहां एक स्नैपशॉट शामिल किया गया है:

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

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

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

android:sharedUserId="android.uid.system"

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

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

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

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>

यह ट्रेड फेडरेशन को एक निर्दिष्ट 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>

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

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

JUnit4 सुविधाएँ

टेस्ट रनर के रूप में 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() {
    ...

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

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

एक्सेसिंग instrumentation

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

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

Instrumentation क्लास के उदाहरण तक पहुंचने के लिए, InstrumentationRegistry रजिस्ट्री क्लास पर स्थिर विधि getInstrumentation() को कॉल करें:

Instrumentation instrumentation = InstrumentationRegistry.getInstrumentation()

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

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

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