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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

android:sharedUserId="android.uid.system"

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

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

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

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

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

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

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

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

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

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

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

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

तक पहुंचना instrumentation

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

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

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

Instrumentation instrumentation = InstrumentationRegistry.getInstrumentation()

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

सबसे आम उपयोग के मामलों के लिए, काम atest

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