एक आवेदन उदाहरण को लक्षित करना

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

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

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

• रूपरेखा/आधार/पैकेज/शैल/परीक्षण

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

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

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

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

प्रकट फ़ाइल

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

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

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

नमूना गेरिट परिवर्तन के लिए मेनिफेस्ट फ़ाइल का नवीनतम संस्करण यहां देखा जा सकता है: https://android.googlesource.com/platform/frameworks/base/+/main/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 पर सेट करता है। जब इंस्ट्रूमेंटेशन को am instrument कमांड के माध्यम से लागू किया जाता है, तो फ्रेमवर्क com.android.shell प्रक्रिया को पुनरारंभ करता है, और परीक्षण निष्पादन के लिए प्रक्रिया में इंस्ट्रूमेंटेशन कोड इंजेक्ट करता है। इसका मतलब यह भी है कि परीक्षण कोड के पास परीक्षण के तहत एप्लिकेशन में चल रहे सभी वर्ग उदाहरणों तक पहुंच होगी और उजागर किए गए परीक्षण हुक के आधार पर स्थिति में हेरफेर करने में सक्षम हो सकता है।

सरल कॉन्फ़िगरेशन फ़ाइल

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

जटिल कॉन्फ़िगरेशन फ़ाइल

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

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

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

नमूना गेरिट परिवर्तन के लिए कॉन्फ़िगरेशन फ़ाइल का नवीनतम संस्करण यहां एक्सेस किया जा सकता है: फ्रेमवर्क/बेस/पैकेज/शेल/टेस्ट/एंड्रॉइडटेस्ट.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 एनोटेशन ने संपूर्ण परीक्षण वर्ग के लिए एक परीक्षण आकार निर्दिष्ट किया है: इस परीक्षण वर्ग में जोड़े गए सभी परीक्षण तरीकों को यह परीक्षण आकार एनोटेशन प्राप्त होता है। प्री टेस्ट क्लास सेटअप, पोस्ट टेस्ट टियर डाउन, और पोस्ट टेस्ट क्लास टियर डाउन: JUnit4 में setUp और tearDown तरीकों के समान। Test एनोटेशन का उपयोग वास्तविक परीक्षण को एनोटेट करने के लिए किया जाता है।

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

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

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

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

        Context context = InstrumentationRegistry.getTargetContext();

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

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

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

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

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