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

संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.

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

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

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

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

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

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

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

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

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

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

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

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

संरचना के बावजूद, आप tests निर्देशिका या नई बनाई गई उप निर्देशिका को नमूना gerrit परिवर्तन में 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 विशेषता एप्लिकेशन पैकेज नाम है: यह विशिष्ट पहचानकर्ता है जिसका उपयोग एंड्रॉइड एप्लिकेशन फ्रेमवर्क किसी एप्लिकेशन की पहचान करने के लिए करता है (या इस संदर्भ में: आपका परीक्षण एप्लिकेशन)। सिस्टम में प्रत्येक उपयोगकर्ता उस पैकेज नाम के साथ केवल एक एप्लिकेशन इंस्टॉल कर सकता है।

इसके अलावा, यह 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 विशेषता के समान ही घोषित किया गया है। जैसा कि टेस्टिंग बेसिक्स में बताया गया है, इंस्ट्रूमेंटेशन टेस्ट की यह श्रेणी आम तौर पर फ्रेमवर्क एपीआई के परीक्षण के लिए होती है, इसलिए उनके लिए एक विशिष्ट लक्षित एप्लिकेशन पैकेज होना बहुत सार्थक नहीं है, इसके अलावा अन्य।

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

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

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

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

परीक्षण कॉन्फ़िगरेशन परीक्षण वर्ग की आपूर्ति के लिए विशेष उपकरण सेटअप विकल्प और डिफ़ॉल्ट तर्क निर्दिष्ट कर सकता है। उदाहरण को /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>

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

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

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

परीक्षण रनर के रूप में android-support-test लाइब्रेरी का उपयोग करने से नई JUnit4 शैली परीक्षण कक्षाओं को अपनाने में मदद मिलती है, और नमूना gerrit परिवर्तन में इसकी विशेषताओं का कुछ बहुत ही बुनियादी उपयोग होता है। उदाहरण को /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 द्वारा टेस्ट क्लास में सभी परीक्षणों को निष्पादित करने से पहले सेटअप करने के लिए और बाद में टियरडाउन करने के तरीकों पर किया जाता है। ध्यान दें कि क्लास-स्कोप सेटअप और टियरडाउन विधियां स्थिर होनी चाहिए। परीक्षण विधियों के लिए, जुनीट के पुराने संस्करण के विपरीत, उन्हें अब test के साथ विधि नाम शुरू करने की आवश्यकता नहीं है, इसके बजाय, उनमें से प्रत्येक को @Test के साथ एनोटेट किया जाना चाहिए। हमेशा की तरह, परीक्षण विधियों को सार्वजनिक होना चाहिए, कोई वापसी मूल्य घोषित नहीं करना चाहिए, कोई पैरामीटर नहीं लेना चाहिए, और अपवाद फेंक सकते हैं।

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

एक्सेसिंग instrumentation

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

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

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

Instrumentation instrumentation = InstrumentationRegistry.getInstrumentation()

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

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

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