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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

android:targetPackage="com.android.shell"

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

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

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

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

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

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

नमूना Gerrit बदलाव के लिए कॉन्फ़िग फ़ाइल का नवीनतम संस्करण में पहुँचा जा सकता है: चौखटे / आधार / संकुल / शैल / परीक्षण / 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>

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

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

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

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

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

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

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

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

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

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

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

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

        Context context = InstrumentationRegistry.getTargetContext();

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

  • getInstrumentation() : करने के लिए उदाहरण Instrumentation वर्ग
  • getArguments() : आदेश पंक्ति तर्क के लिए पारित am instrument के माध्यम से -e <key> <value>

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

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

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