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

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

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

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

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

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

इंस्ट्रुमेंट किए गए टेस्ट को किसी बिल्ड के वैरिएंट से लिंक करने के लिए, उन्हें अपने source set में रखें. यह src/androidTestVariantName पर मौजूद होता है.

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

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

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

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

यहां दी गई टेबल में, यह दिखाया गया है कि इंस्ट्रुमेंटेशन टेस्ट फ़ाइलें, ऐप्लिकेशन के कोड सोर्स सेट से जुड़ी सोर्स सेट में कैसे मौजूद हो सकती हैं:

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

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

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

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

अगर प्रोजेक्ट व्यू का इस्तेमाल किया जा रहा है, तो यह थोड़ा अलग दिखता है. हालांकि, सिद्धांत वही रहता है:

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

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

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

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

इस नोड के लिए अन्य सेटिंग बदलने के लिए, टेस्ट source set में कोई दूसरी मेनिफ़ेस्ट फ़ाइल बनाएं या मॉड्यूल-लेवल की 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
    }
}

कॉन्फ़िगर किया गया हर प्रॉडक्ट फ़्लेवर, defaultConfig {} ब्लॉक में मौजूद प्रॉपर्टी को बदल सकता है. ज़्यादा जानने के लिए, प्रॉडक्ट फ़्लेवर कॉन्फ़िगर करना पर जाएं.

स्निपेट में मौजूद प्रॉपर्टी ये हैं:

टेस्ट बिल्ड का टाइप बदलना

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

android {
    ...
    testBuildType = "staging"
}

android {
    ...
    testBuildType "staging"
}

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

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

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, मौजूदा प्रोजेक्ट की रूट डायरेक्ट्री के हिसाब से पाथ सेट करता है.

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

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 {
    ...
    testOptions {
        ...
        // Encapsulates options for local unit tests.
        unitTests {
            returnDefaultValues true

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

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

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

all ब्लॉक में, यह कंट्रोल करने के विकल्प शामिल होते हैं कि Gradle, लोकल यूनिट टेस्ट कैसे एक्ज़ीक्यूट करता है. आपके पास जो भी विकल्प हैं उनकी सूची देखने के लिए, Gradle का रेफ़रंस दस्तावेज़ पढ़ें.

jvmArgs प्रॉपर्टी, टेस्ट जेवीएम के लिए जेवीएम आर्ग्युमेंट सेट करती है.

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

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

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

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

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

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

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

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

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

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