Android Studio में टेस्ट करना और कमांड लाइन से जांच करना, सेट करने का तरीका बताओ बुनियादी टेस्ट कॉन्फ़िगरेशन बनाए जा सकते हैं. हालांकि, जब आपका ऐप्लिकेशन और की जांच की ज़रूरतें और ऐडवांस होती हैं, आपको टेस्ट में अपने हिसाब से बदलाव करने पड़ सकते हैं कॉन्फ़िगरेशन की शर्तों को पूरा करना होगा. उदाहरण के लिए, ऐडवांस टेस्ट सेटअप की ज़रूरत तब पड़ सकती है, जब आपको नीचे दिए गए काम करने हैं:
- किसी खास बिल्ड वैरिएंट के लिए ही इंस्ट्रुमेंट्ड टेस्ट करें या इसके मेनिफ़ेस्ट सेटिंग में सेव किया जाएगा.
- टेस्ट चलाने के लिए, बिल्ड टाइप को बदलें या इसके Gradle को कॉन्फ़िगर करें के विकल्प.
- अपने इंस्ट्रुमेंटेड टेस्ट को उनके टेस्ट मॉड्यूल में निकालें.
- अपने कंटिन्यूअस इंटिग्रेशन सेटअप के हिस्से के तौर पर, ज़्यादा बेहतर टेस्टिंग करें.
इस पेज में, जांच को कॉन्फ़िगर करने के अलग-अलग तरीकों के बारे में बताया गया है. यह जानकारी, डिफ़ॉल्ट तौर पर सेटिंग आपकी ज़रूरतों के मुताबिक नहीं हैं.
बिल्ड वैरिएंट के लिए इंस्ट्रुमेंटेड टेस्ट बनाना
अगर आपके प्रोजेक्ट में बिल्ड वैरिएंट शामिल हैं, तो अगर आपको यूनीक सोर्स सेट इस्तेमाल करने हैं, तो हो सकता है कि आप ऐसे इंस्ट्रुमेंटेड टेस्ट शामिल करना चाहें वैल्यू, उन सोर्स सेट से मेल खाती हों. इससे आपका टेस्ट कोड व्यवस्थित रहता है और आपको सिर्फ़ वे टेस्ट चलाने की सुविधा देता है जो दिए गए बिल्ड वैरिएंट पर लागू होते हैं.
इंस्ट्रुमेंट्ड टेस्ट को बिल्ड वैरिएंट से लिंक करने के लिए, उन्हें अपने-आप टेस्ट करने की जगह दें
सोर्स सेट, जो कि
src/androidTestVariantName
.
src/androidTest/
सोर्स सेट में, इंस्ट्रुमेंट किए गए टेस्ट सभी शेयर किए जाते हैं
बिल्ड वैरिएंट. "MyFlavor" के लिए टेस्ट APK बनाते समय आपके स्टोर का वैरिएंट
ऐप्लिकेशन के तौर पर, Gradle, src/androidTest/
और src/androidTestMyFlavor/
को जोड़ता है
सोर्स सेट का इस्तेमाल करें.
Android Studio में अपने बिल्ड वैरिएंट के लिए टेस्टिंग सोर्स सेट जोड़ने के लिए, यह तरीका अपनाएं यह तरीका अपनाएं:
- प्रोजेक्ट विंडो में, मेन्यू पर क्लिक करें और प्रोजेक्ट व्यू.
- सही मॉड्यूल फ़ोल्डर में, src फ़ोल्डर पर राइट क्लिक करें और नया > डायरेक्ट्री.
- डायरेक्ट्री के नाम के लिए, "androidTestVariantName" डालें. उदाहरण के लिए, अगर
आपके पास "MyFlavor" नाम का एक बिल्ड वैरिएंट है. डायरेक्ट्री के नाम का इस्तेमाल करें
androidTestMyFlavor
. - ठीक है पर क्लिक करें.
- नई डायरेक्ट्री पर राइट-क्लिक करें और New > चुनें डायरेक्ट्री.
- "java" डालें को डायरेक्ट्री का नाम डालें और ठीक है पर क्लिक करें.
अब इस नए सोर्स सेट में टेस्ट जोड़ने के लिए, यहां दिया गया तरीका अपनाएं: नया टेस्ट जोड़ने का तरीका. डेस्टिनेशन डायरेक्ट्री चुनें डायलॉग पर पहुंचने के बाद, नई वैरिएंट टेस्ट सोर्स सेट.
नीचे दी गई टेबल में एक उदाहरण दिया गया है. इसमें बताया गया है कि इंस्ट्रुमेंटेशन की जांच वाली फ़ाइलें उन स्रोत सेट में मौजूद होना चाहिए जो ऐप्लिकेशन के कोड स्रोत सेट से संबंधित होते हैं:
टेबल 1. ऐप्लिकेशन का सोर्स कोड और उससे जुड़े ऐप्लिकेशन इंस्ट्रुमेंटेशन टेस्ट फ़ाइलें
ऐप्लिकेशन क्लास का पाथ | इंस्ट्रुमेंटेशन टेस्ट क्लास से मेल खाने वाले पाथ का पाथ |
---|---|
src/main/java/Example.java
|
src/androidTest/java/AndroidExampleTest.java
|
src/myFlavor/java/Example.java
|
src/androidTestMyFlavor/java/AndroidExampleTest.java
|
आपके ऐप्लिकेशन के सोर्स सेट की तरह ही, Gradle बिल्ड मर्ज करता है और
यह फ़ंक्शन, अलग-अलग टेस्ट सोर्स सेट की फ़ाइलों को बदल देता है. इस मामले में,
androidTestMyFlavor
सोर्स सेट में मौजूद AndroidExampleTest.java
फ़ाइल में बदलाव किया गया
androidTest
स्रोत सेट में वर्शन. ऐसा इसलिए है, क्योंकि
प्रॉडक्ट फ़्लेवर के सोर्स सेट को मुख्य सोर्स सेट के मुकाबले प्राथमिकता दी जाती है.
जब बिल्ड के वैरिएंट चुनने वाले टूल में अलग-अलग फ़्लेवर चुने जाते हैं, तो
Android व्यू में सही androidTest
फ़ोल्डर दिखाए जाते हैं, ताकि
वे फ़ोल्डर दिखाएं जिनका इस्तेमाल किया गया है:
![MyFlaver वैरिएंट चुना गया है और androidTestMyFlavor फ़ोल्डर दिखाया गया है
Android व्यू में](https://developer.android.com/static/studio/images/test/test-myflavor-android-test-android-view.png?authuser=9&hl=hi)
MyFlavor
वैरिएंट चुना गया; यह
Android व्यू में androidTestMyFlavor
फ़ोल्डर दिखता है.कोई दूसरा वैरिएंट होने पर, androidTestMyFlavor
फ़ोल्डर नहीं दिखाया जाता
चुना गया:
![OtherFlaver वैरिएंट चुना गया और androidTestMyFlavor फ़ोल्डर में नहीं है
Android व्यू में दिखाया गया है](https://developer.android.com/static/studio/images/test/test-otherflavor-android-test-android-view.png?authuser=9&hl=hi)
OtherFlavor
वैरिएंट चुना गया; यह
androidTestMyFlavor
फ़ोल्डर, Android व्यू में नहीं दिखता.अगर प्रोजेक्ट व्यू का इस्तेमाल किया जा रहा है, तो यह कुछ अलग दिखता है, लेकिन सिद्धांत लागू होता है:
![MyFlavor वैरिएंट चुना गया और androidTestMyFlavor फ़ोल्डर चालू है
प्रोजेक्ट व्यू में](https://developer.android.com/static/studio/images/test/test-myflavor-android-test-project-view.png?authuser=9&hl=hi)
MyFlavor
वैरिएंट चुना गया; यह
प्रोजेक्ट व्यू में androidTestMyFlavor
फ़ोल्डर चालू है.कोई दूसरा वैरिएंट चुनने पर, androidTestMyFlavor
फ़ोल्डर तब भी बना रहता है
दिखाई दे रहा है, लेकिन यह 'चालू है' के तौर पर नहीं दिख रहा है:
![OtherFlaver वैरिएंट चुना गया और androidTestMyFlavor फ़ोल्डर में नहीं है
प्रोजेक्ट व्यू में ऐक्टिव है](https://developer.android.com/static/studio/images/test/test-otherflavor-android-test-project-view.png?authuser=9&hl=hi)
OtherFlavor
वैरिएंट चुना गया; यह
प्रोजेक्ट व्यू में 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 } }
Kotlin
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:
Setting | Description |
---|---|
testApplicationId
|
Specifies the application ID for the test APK. |
testInstrumentationRunner
|
Specifies the fully qualified class name of the test instrumentation runner. |
testHandleProfiling
|
If set to true , enables the instrumentation class
to start and stop profiling.If set to false , profiling occurs the entire time
the instrumentation class is running. |
testFunctionalTest
|
If set to true , indicates that the Android system
should run the instrumentation class as a functional
test.The default value is false . |
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:
Groovy
android { ... testBuildType "staging" }
Kotlin
android { ... testBuildType = "staging" }
Gradle टेस्ट के विकल्प कॉन्फ़िगर करें
Android Gradle प्लग इन आपको
अपने सभी या कुछ टेस्ट के लिए कुछ विकल्प तय करें. इस
मॉड्यूल-लेवल build.gradle
फ़ाइल में,
testOptions
ब्लॉक करें:
ग्रूवी
android { ... // Encapsulates options for running tests. testOptions { reportDir "$rootDir/test-reports" resultsDir "$rootDir/test-results" } }
Kotlin
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' } ... } } } }
Kotlin
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
टास्क के लिए इस्तेमाल किया जा सकता है.
इंस्ट्रुमेंट्ड टेस्ट के लिए, अलग-अलग मॉड्यूल का इस्तेमाल करना
अगर आपको इंस्ट्रुमेंट वाले टेस्ट के लिए कोई खास मॉड्यूल चाहिए, तो टेस्ट करने के लिए, अपने बाकी के कोड को टेस्ट करने के लिए, एक अलग टेस्ट मॉड्यूल बनाएं और इसके बिल्ड को लाइब्रेरी मॉड्यूल के समान कॉन्फ़िगर करें.
टेस्ट मॉड्यूल बनाने के लिए, यहां दिया गया तरीका अपनाएं:
- लाइब्रेरी मॉड्यूल बनाएं.
- मॉड्यूल-लेवल
build.gradle
फ़ाइल में,com.android.test
को लागू करेंcom.android.library
के बजाय प्लगिन का इस्तेमाल करें. - प्रोजेक्ट सिंक करें
पर क्लिक करें.
टेस्ट मॉड्यूल बनाने के बाद, इसमें टेस्ट कोड को शामिल किया जा सकता है
मुख्य या वैरिएंट का सोर्स सेट (उदाहरण के लिए, src/main/java
या
src/variant/java
). अगर आपके ऐप्लिकेशन मॉड्यूल को
कई तरह के प्रॉडक्ट के लिए, टेस्ट मॉड्यूल में उन फ़्लेवर को फिर से बनाया जा सकता है.
वैरिएंट-अवेयर डिपेंडेंसी का इस्तेमाल करना
मैनेजमेंट,
टेस्ट मॉड्यूल में, टारगेट मॉड्यूल में मैचिंग फ़्लेवर की जांच करने की कोशिश की जाती है.
डिफ़ॉल्ट रूप से, टेस्ट मॉड्यूल में सिर्फ़ डीबग वैरिएंट होता है और उसकी जांच की जाती है. हालांकि,
जांचे गए ऐप्लिकेशन प्रोजेक्ट से मैच करने के लिए, नए बिल्ड टाइप बनाए जा सकते हैं. आसानी से
परीक्षण मॉड्यूल एक भिन्न बिल्ड प्रकार का परीक्षण करें न कि डीबग करें, इसका उपयोग करें
टेस्ट प्रोजेक्ट में डीबग वैरिएंट को बंद करने के लिए, VariantFilter
को इस तरह देखें:
ग्रूवी
android { variantFilter { variant -> if (variant.buildType.name.equals('debug')) { variant.setIgnore(true); } } }
Kotlin
android { variantFilter { if (buildType.name == "debug") { ignore = true } } }
अगर आपको किसी टेस्ट मॉड्यूल से सिर्फ़ खास फ़्लेवर या बिल्ड टाइप को टारगेट करना है, तो
तो matchingFallbacks
का इस्तेमाल किया जा सकता है
प्रॉपर्टी का इस्तेमाल करें, ताकि सिर्फ़ उन वैरिएंट को टारगेट किया जा सके जिनका आपको टेस्ट करना है. यह प्रोसेस,
टेस्ट मॉड्यूल का इस्तेमाल करके, उन वैरिएंट को खुद ही कॉन्फ़िगर नहीं किया जा सकता.