ऐडवांस टेस्ट सेटअप

Android Studio में टेस्ट करना और कमांड लाइन से जांच करना, सेट करने का तरीका बताओ बुनियादी टेस्ट कॉन्फ़िगरेशन बनाए जा सकते हैं. हालांकि, जब आपका ऐप्लिकेशन और की जांच की ज़रूरतें और ऐडवांस होती हैं, आपको टेस्ट में अपने हिसाब से बदलाव करने पड़ सकते हैं कॉन्फ़िगरेशन की शर्तों को पूरा करना होगा. उदाहरण के लिए, ऐडवांस टेस्ट सेटअप की ज़रूरत तब पड़ सकती है, जब आपको नीचे दिए गए काम करने हैं:

• किसी खास बिल्ड वैरिएंट के लिए ही इंस्ट्रुमेंट्ड टेस्ट करें या इसके मेनिफ़ेस्ट सेटिंग में सेव किया जाएगा.
• टेस्ट चलाने के लिए, बिल्ड टाइप को बदलें या इसके Gradle को कॉन्फ़िगर करें के विकल्प.
• अपने इंस्ट्रुमेंटेड टेस्ट को उनके टेस्ट मॉड्यूल में निकालें.
• अपने कंटिन्यूअस इंटिग्रेशन सेटअप के हिस्से के तौर पर, ज़्यादा बेहतर टेस्टिंग करें.

इस पेज में, जांच को कॉन्फ़िगर करने के अलग-अलग तरीकों के बारे में बताया गया है. यह जानकारी, डिफ़ॉल्ट तौर पर सेटिंग आपकी ज़रूरतों के मुताबिक नहीं हैं.

बिल्ड वैरिएंट के लिए इंस्ट्रुमेंटेड टेस्ट बनाना

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

इंस्ट्रुमेंट्ड टेस्ट को बिल्ड वैरिएंट से लिंक करने के लिए, उन्हें अपने-आप टेस्ट करने की जगह दें सोर्स सेट, जो कि src/androidTestVariantName.

src/androidTest/ सोर्स सेट में, इंस्ट्रुमेंट किए गए टेस्ट सभी शेयर किए जाते हैं बिल्ड वैरिएंट. "MyFlavor" के लिए टेस्ट APK बनाते समय आपके स्टोर का वैरिएंट ऐप्लिकेशन के तौर पर, Gradle, src/androidTest/ और src/androidTestMyFlavor/ को जोड़ता है सोर्स सेट का इस्तेमाल करें.

Android Studio में अपने बिल्ड वैरिएंट के लिए टेस्टिंग सोर्स सेट जोड़ने के लिए, यह तरीका अपनाएं यह तरीका अपनाएं:

1. प्रोजेक्ट विंडो में, मेन्यू पर क्लिक करें और प्रोजेक्ट व्यू.
2. सही मॉड्यूल फ़ोल्डर में, src फ़ोल्डर पर राइट क्लिक करें और नया > डायरेक्ट्री.
3. डायरेक्ट्री के नाम के लिए, "androidTestVariantName" डालें. उदाहरण के लिए, अगर आपके पास "MyFlavor" नाम का एक बिल्ड वैरिएंट है. डायरेक्ट्री के नाम का इस्तेमाल करें androidTestMyFlavor.
4. ठीक है पर क्लिक करें.
5. नई डायरेक्ट्री पर राइट-क्लिक करें और New > चुनें डायरेक्ट्री.
6. "java" डालें को डायरेक्ट्री का नाम डालें और ठीक है पर क्लिक करें.

अब इस नए सोर्स सेट में टेस्ट जोड़ने के लिए, यहां दिया गया तरीका अपनाएं: नया टेस्ट जोड़ने का तरीका. डेस्टिनेशन डायरेक्ट्री चुनें डायलॉग पर पहुंचने के बाद, नई वैरिएंट टेस्ट सोर्स सेट.

नीचे दी गई टेबल में एक उदाहरण दिया गया है. इसमें बताया गया है कि इंस्ट्रुमेंटेशन की जांच वाली फ़ाइलें उन स्रोत सेट में मौजूद होना चाहिए जो ऐप्लिकेशन के कोड स्रोत सेट से संबंधित होते हैं:

टेबल 1. ऐप्लिकेशन का सोर्स कोड और उससे जुड़े ऐप्लिकेशन इंस्ट्रुमेंटेशन टेस्ट फ़ाइलें

आपके ऐप्लिकेशन के सोर्स सेट की तरह ही, Gradle बिल्ड मर्ज करता है और यह फ़ंक्शन, अलग-अलग टेस्ट सोर्स सेट की फ़ाइलों को बदल देता है. इस मामले में, androidTestMyFlavor सोर्स सेट में मौजूद AndroidExampleTest.java फ़ाइल में बदलाव किया गया androidTest स्रोत सेट में वर्शन. ऐसा इसलिए है, क्योंकि प्रॉडक्ट फ़्लेवर के सोर्स सेट को मुख्य सोर्स सेट के मुकाबले प्राथमिकता दी जाती है.

जब बिल्ड के वैरिएंट चुनने वाले टूल में अलग-अलग फ़्लेवर चुने जाते हैं, तो Android व्यू में सही androidTest फ़ोल्डर दिखाए जाते हैं, ताकि वे फ़ोल्डर दिखाएं जिनका इस्तेमाल किया गया है:

कोई दूसरा वैरिएंट होने पर, androidTestMyFlavor फ़ोल्डर नहीं दिखाया जाता चुना गया:

अगर प्रोजेक्ट व्यू का इस्तेमाल किया जा रहा है, तो यह कुछ अलग दिखता है, लेकिन सिद्धांत लागू होता है:

कोई दूसरा वैरिएंट चुनने पर, androidTestMyFlavor फ़ोल्डर तब भी बना रहता है दिखाई दे रहा है, लेकिन यह 'चालू है' के तौर पर नहीं दिख रहा है:

सोर्स सेट को मर्ज करने के तरीके के बारे में ज़्यादा जानने के लिए, यह देखें सोर्स सेट.

इंस्ट्रुमेंटेशन मेनिफ़ेस्ट सेटिंग कॉन्फ़िगर करें

इंस्ट्रुमेंट वाले टेस्ट अपने ऐप्लिकेशन के साथ एक अलग APK में बनाए गए हैं AndroidManifest.xml फ़ाइल. जब Gradle आपका टेस्ट APK बनाता है, तब यह AndroidManifest.xml फ़ाइल अपने-आप जनरेट करती है और उसे कॉन्फ़िगर करती है के साथ <instrumentation> नोड. आपके लिए Gradle इस नोड को कॉन्फ़िगर करता है, इसके पीछे एक वजह यह पक्का करना है कि targetPackage प्रॉपर्टी, टेस्ट किए जा रहे ऐप्लिकेशन के पैकेज का सही नाम बताती है.

इस नोड की दूसरी सेटिंग बदलने के लिए, या तो दूसरी सेटिंग बनाएं टेस्ट सोर्स सेट में मेनिफ़ेस्ट फ़ाइल खोलें या अपने मॉड्यूल-लेवल को कॉन्फ़िगर करें build.gradle फ़ाइल, जैसा कि यहां दिखाया गया है नीचे दिया गया कोड सैंपल देखें. विकल्पों की पूरी सूची यहां देखी जा सकती है: BaseFlavor एपीआई का संदर्भ.

android {
    ...
    defaultConfig {
        ...
        testApplicationId "com.example.test"
        testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
        testHandleProfiling true
        testFunctionalTest true
    }
}

android {
    ...
    defaultConfig {
        ...
        testApplicationId = "com.example.test"
        testInstrumentationRunner = "androidx.test.runner.AndroidJUnitRunner"
        testHandleProfiling = true
        testFunctionalTest = true
    }
}

Each product flavor you configure can override properties in the defaultConfig {} block. To learn more, go to Configure product flavors.

The properties in the snippet are:

Change the test build type

By default, all instrumentation tests run against the debug build type. You can change this to another build type by using the testBuildType property in your module-level build.gradle file. For example, if you want to run your tests against your staging build type, edit the file as shown in the following snippet:

android {
    ...
    testBuildType "staging"
}

android {
    ...
    testBuildType = "staging"
}

Gradle टेस्ट के विकल्प कॉन्फ़िगर करें

Android Gradle प्लग इन आपको अपने सभी या कुछ टेस्ट के लिए कुछ विकल्प तय करें. इस मॉड्यूल-लेवल build.gradle फ़ाइल में, testOptions ब्लॉक करें:

android {
    ...
    // Encapsulates options for running tests.
    testOptions {
        reportDir "$rootDir/test-reports"
        resultsDir "$rootDir/test-results"
    }
}

android {
    ...
    // Encapsulates options for running tests.
    testOptions {
        reportDir "$rootDir/test-reports"
        resultsDir = "$rootDir/test-results"
    }
}

reportDir प्रॉपर्टी उस डायरेक्ट्री को बदल देती है जिसमें Gradle टेस्ट सेव करता है रिपोर्ट. डिफ़ॉल्ट रूप से, Gradle, टेस्ट रिपोर्ट को path_to_your_project/module_name /build/outputs/reports/ डायरेक्ट्री. $rootDir संबंधित पथ सेट करता है को मौजूदा प्रोजेक्ट की रूट डायरेक्ट्री में स्टोर करें.

resultsDir प्रॉपर्टी उस डायरेक्ट्री को बदल देती है जिसमें Gradle टेस्ट सेव करता है नतीजे. डिफ़ॉल्ट रूप से, Gradle, जांच के नतीजे path_to_your_project/module_name /build/outputs/test-results/ डायरेक्ट्री. $rootDir संबंधित पथ सेट करता है को मौजूदा प्रोजेक्ट की रूट डायरेक्ट्री में स्टोर करें.

सिर्फ़ लोकल यूनिट टेस्ट के विकल्प तय करने के लिए, unitTests testOptions के अंदर ब्लॉक करें.

android {
    ...
    testOptions {
        ...
        // Encapsulates options for local unit tests.
        unitTests {
            returnDefaultValues true

            all {
                jvmArgs '-XX:MaxPermSize=256m'

                if (it.name == 'testDebugUnitTest') {
                    systemProperty 'debug', 'true'
                }
                ...
            }
        }
    }
}

android {
    ...
    testOptions {
        ...
        // Encapsulates options for local unit tests.
        unitTests {
            returnDefaultValues = true

            all {
                jvmArgs = listOf("-XX:MaxPermSize=256m")

                 if (it.name == "testDebugUnitTest") {
                    systemProperty = mapOf("debug" to "true")
                }
                ...
            }
        }
    }
}

डिफ़ॉल्ट रूप से, जब भी कोड में लोकल यूनिट की जांच होती है, तो उसे अपवाद माना जाता है की जांच कर रहा हो, तब तक Android प्लैटफ़ॉर्म एपीआई ऐक्सेस करने की कोशिश न की जाए, जब तक कि मॉक Android डिपेंडेंसी या टेस्टिंग फ़्रेमवर्क का इस्तेमाल करें, जैसे कि मॉकिटो. हालांकि, returnDefaultValues प्रॉपर्टी को चालू किया जा सकता है, ताकि प्लैटफ़ॉर्म एपीआई ऐक्सेस करते समय, टेस्ट शून्य या शून्य दिखाता है, कोई अपवाद नहीं है.

all ब्लॉक, उन विकल्पों को इकट्ठा करता है जिनसे यह कंट्रोल किया जा सकता है कि Gradle कैसे काम करेगा स्थानीय इकाई परीक्षण. आपके ज़रिए तय किए जा सकने वाले सभी विकल्पों की सूची के लिए, पढ़ें Gredle के रेफ़रंस दस्तावेज़.

jvmArgs प्रॉपर्टी, जांच JVM के लिए JVM तर्क सेट करती है.

इसके अलावा, सिर्फ़ उन जांचों के लिए विकल्प लागू किए जा सकते हैं जिन्हें आपने टेस्ट करने के लिए चुना है. इसके लिए, आपको टास्क के नाम की जांच करनी होगी तय करें. उदाहरण के तौर पर दिए गए स्निपेट में, debug प्रॉपर्टी true पर सेट है, लेकिन इसे सिर्फ़ testDebugUnitTest टास्क के लिए इस्तेमाल किया जा सकता है.

इंस्ट्रुमेंट्ड टेस्ट के लिए, अलग-अलग मॉड्यूल का इस्तेमाल करना

अगर आपको इंस्ट्रुमेंट वाले टेस्ट के लिए कोई खास मॉड्यूल चाहिए, तो टेस्ट करने के लिए, अपने बाकी के कोड को टेस्ट करने के लिए, एक अलग टेस्ट मॉड्यूल बनाएं और इसके बिल्ड को लाइब्रेरी मॉड्यूल के समान कॉन्फ़िगर करें.

टेस्ट मॉड्यूल बनाने के लिए, यहां दिया गया तरीका अपनाएं:

1. लाइब्रेरी मॉड्यूल बनाएं.
2. मॉड्यूल-लेवल build.gradle फ़ाइल में, com.android.test को लागू करें com.android.library के बजाय प्लगिन का इस्तेमाल करें.
3. प्रोजेक्ट सिंक करें पर क्लिक करें.

टेस्ट मॉड्यूल बनाने के बाद, इसमें टेस्ट कोड को शामिल किया जा सकता है मुख्य या वैरिएंट का सोर्स सेट (उदाहरण के लिए, src/main/java या src/variant/java). अगर आपके ऐप्लिकेशन मॉड्यूल को कई तरह के प्रॉडक्ट के लिए, टेस्ट मॉड्यूल में उन फ़्लेवर को फिर से बनाया जा सकता है. वैरिएंट-अवेयर डिपेंडेंसी का इस्तेमाल करना मैनेजमेंट, टेस्ट मॉड्यूल में, टारगेट मॉड्यूल में मैचिंग फ़्लेवर की जांच करने की कोशिश की जाती है.

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

android {
    variantFilter { variant ->
        if (variant.buildType.name.equals('debug')) {
            variant.setIgnore(true);
        }
    }
}

android {
    variantFilter {
        if (buildType.name == "debug") {
            ignore = true
        }
    }
}

अगर आपको किसी टेस्ट मॉड्यूल से सिर्फ़ खास फ़्लेवर या बिल्ड टाइप को टारगेट करना है, तो तो matchingFallbacks का इस्तेमाल किया जा सकता है प्रॉपर्टी का इस्तेमाल करें, ताकि सिर्फ़ उन वैरिएंट को टारगेट किया जा सके जिनका आपको टेस्ट करना है. यह प्रोसेस, टेस्ट मॉड्यूल का इस्तेमाल करके, उन वैरिएंट को खुद ही कॉन्फ़िगर नहीं किया जा सकता.