स्व-यंत्र परीक्षण उदाहरण

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

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

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

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

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

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

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

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

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

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

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

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

संरचना के बावजूद, आप नमूना गेरिट परिवर्तन में instrumentation निर्देशिका में मौजूद फ़ाइलों के समान tests निर्देशिका या नव निर्मित उप निर्देशिका को पॉप्युलेट कर देंगे। प्रत्येक फ़ाइल का विवरण इस दस्तावेज़ में बाद में बताया गया है।

प्रकट फ़ाइल

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

इसके अलावा, यह package विशेषता वही है जो ComponentName#getPackageName() लौटाती है, और यह भी वही है जिसका उपयोग आप विभिन्न pm उप कमांडों के साथ बातचीत करने के लिए adb shell उपयोग करेंगे।

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

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>

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

इंस्ट्रुमेंटेशन क्लास तक पहुंच

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

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

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

Instrumentation instrumentation = InstrumentationRegistry.getInstrumentation()

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

सबसे आम उपयोग के मामलों के लिए, एटेस्ट का उपयोग करें।

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