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

एक अनुप्रयोग उदाहरण लक्ष्यीकरण

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

ध्यान दें कि यह मार्गदर्शिका मानती है कि आपके पास पहले से ही प्लेटफॉर्म स्रोत ट्री वर्कफ़्लो में कुछ ज्ञान है। यदि नहीं, तो कृपया https://source.android.com/source/requirements देखें। यहां कवर किया गया उदाहरण अपने स्वयं के परीक्षण एप्लिकेशन पैकेज पर सेट किए गए लक्ष्य पैकेज के साथ एक नया इंस्ट्रूमेंटेशन टेस्ट लिख रहा है। यदि आप अवधारणा से अपरिचित हैं, तो कृपया प्लेटफ़ॉर्म परीक्षण परिचय के माध्यम से पढ़ें।

यह मार्गदर्शिका एक नमूने के रूप में कार्य करने के लिए निम्नलिखित परीक्षण का उपयोग करती है:

  • चौखटे / आधार / संकुल / शैल / परीक्षण

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

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

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

स्व-इंस्ट्रूमेंटिंग परीक्षणों के लिए एंड-टू-एंड उदाहरण में स्रोत स्थान के बारे में अधिक चर्चाएँ देखें।

प्रकट फ़ाइल

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

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

यह एक मैनिफ़ेस्ट फ़ाइल के मूल घटकों और उनकी कार्यक्षमताओं का अवलोकन देता है।

नमूना जेरिट परिवर्तन के लिए मैनिफ़ेस्ट फ़ाइल का नवीनतम संस्करण यहाँ पहुँचा जा सकता है: https://android.googlesource.com/platform/frameworks/base/+/master/packages/Shell/tests/AndroidManifest.xml

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

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.android.shell.tests">

    <application>
        <uses-library android:name="android.test.runner" />

        <activity
            android:name="com.android.shell.ActionSendMultipleConsumerActivity"
            android:label="ActionSendMultipleConsumer"
            android:theme="@android:style/Theme.NoDisplay"
            android:noHistory="true"
            android:excludeFromRecents="true">
            <intent-filter>
                <action android:name="android.intent.action.SEND_MULTIPLE" />
                <category android:name="android.intent.category.DEFAULT" />
                <data android:mimeType="*/*" />
            </intent-filter>
        </activity>
    </application>

    <instrumentation android:name="android.support.test.runner.AndroidJUnitRunner"
        android:targetPackage="com.android.shell"
        android:label="Tests for Shell" />

</manifest>

मैनिफ़ेस्ट फ़ाइल पर कुछ चुनिंदा टिप्पणियां:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.android.shell.tests">

package विशेषता एप्लिकेशन पैकेज नाम है: यह एक अद्वितीय पहचानकर्ता है जो एंड्रॉइड एप्लिकेशन फ्रेमवर्क का उपयोग किसी एप्लिकेशन को पहचानने के लिए करता है (या इस संदर्भ में: आपका परीक्षण एप्लिकेशन)। सिस्टम का प्रत्येक उपयोगकर्ता उस पैकेज के नाम के साथ केवल एक एप्लिकेशन इंस्टॉल कर सकता है।

चूंकि यह एक परीक्षण आवेदन पैकेज, परीक्षण के अंतर्गत आवेदन पैकेज से स्वतंत्र है, एक अलग पैकेज नाम इस्तेमाल किया जाना चाहिए: एक आम सम्मेलन एक प्रत्यय जोड़ना है .test

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

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

<uses-library android:name="android.test.runner" />

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

android:targetPackage="com.android.shell"

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

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

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

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

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

परीक्षण कॉन्फ़िगरेशन विशेष डिवाइस सेटअप विकल्प और डिफ़ॉल्ट तर्क परीक्षण कक्षा की आपूर्ति करने के लिए निर्दिष्ट कर सकता है।

नमूना जेरिट परिवर्तन के लिए कॉन्फ़िगर फ़ाइल का नवीनतम संस्करण यहां पहुँचा जा सकता है: चौखटे / आधार / पैकेज / शेल / परीक्षण / AndroidTest.xml

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

<configuration description="Runs Tests for Shell.">
    <target_preparer class="com.android.tradefed.targetprep.TestAppInstallSetup">
        <option name="test-file-name" value="ShellTests.apk" />
    </target_preparer>

    <option name="test-suite-tag" value="apct" />
    <option name="test-tag" value="ShellTests" />
    <test class="com.android.tradefed.testtype.AndroidJUnitTest" >
        <option name="package" value="com.android.shell.tests" />
        <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="ShellTests.apk"/>
</target_preparer>

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

<test class="com.android.tradefed.testtype.AndroidJUnitTest">
  <option name="package" value="com.android.shell.tests"/>
  <option name="runner" value="android.support.test.runner.AndroidJUnitRunner"/>
</test>

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

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

JUnit4 सुविधाएँ

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

नमूना गेरिट परिवर्तन के लिए नवीनतम स्रोत कोड पर पहुँचा जा सकता है: चौखटे / आधार / पैकेज / शैल / परीक्षण / src / com / android / shell / BugreportReceiverTest.java

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

@SmallTest
@RunWith(AndroidJUnit4.class)
public final class FeatureFactoryImplTest {

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

@SmallTest एनोटेशन ने पूरे परीक्षण वर्ग के लिए एक परीक्षण आकार निर्दिष्ट किया: इस परीक्षण वर्ग में जोड़े गए सभी परीक्षण विधियाँ इस परीक्षण आकार एनोटेशन को इनहेरिट करती हैं। प्री टेस्ट क्लास सेटअप, पोस्ट टेस्ट आंसू डाउन, और पोस्ट टेस्ट क्लास फाड़ नीचे: setUp और tearDown तरीकों के समान tearDown में। Test एनोटेशन का उपयोग वास्तविक Test एनोटेट करने के लिए किया जाता है।

    @Before
    public void setup() {
    ...
    @Test
    public void testGetProvider_shouldCacheProvider() {
    ...

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

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

        Context context = InstrumentationRegistry.getTargetContext();

क्योंकि JUnit4 कोई परीक्षण लंबे समय तक एक आम आधार वर्ग की आवश्यकता होती है, इसे प्राप्त करने के नहीं रह गया है आवश्यक है Context के माध्यम से उदाहरणों getContext() या getTargetContext() आधार वर्ग विधियों के माध्यम से; इसके बजाय, नया परीक्षण धावक उन्हेंInstrumentationRegistry रीजेंसी के माध्यम से प्रबंधित करता है, जहां इंस्ट्रूमेंटेशन फ्रेमवर्क द्वारा निर्मित प्रासंगिक और पर्यावरणीय सेटअप संग्रहीत होता है। इस वर्ग के माध्यम से, आप कॉल भी कर सकते हैं:

  • getInstrumentation() : Instrumentation क्लास के लिए उदाहरण
  • getArguments() : कमांड लाइन आर्ग्युमेंट्स को am instrument getArguments() पास किया जाता है -e <key> <value>

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

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

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