कमांड लाइन से जांच करना

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

Gradle बिल्ड सिस्टम का इस्तेमाल करके ऐप्लिकेशन बनाने पर, Android Gradle प्लगिन आपको कमांड लाइन का इस्तेमाल करके, अपने Gradle प्रोजेक्ट से टेस्ट चलाने की सुविधा देता है. ज़्यादा बेहतर कंट्रोल के लिए, Android डीबग ब्रिज (adb) शेल के ज़रिए टेस्ट चलाए जा सकते हैं. यह लगातार इंटिग्रेशन वाले एनवायरमेंट में टेस्ट चलाने के दौरान काम आ सकता है.

Gradle की मदद से मैनेज किए जाने वाले वर्चुअल डिवाइसों का इस्तेमाल करके, कमांड लाइन से अपने-आप इंस्ट्रुमेंटेड टेस्ट चलाने का तरीका जानने के लिए, Gradle की मदद से मैनेज किए जाने वाले डिवाइसों की मदद से, अपने टेस्ट को स्केल करें लेख पढ़ें.

Gradle की मदद से टेस्ट चलाना

Android Gradle प्लगिन की मदद से, कमांड लाइन का इस्तेमाल करके अपने Gradle प्रोजेक्ट से टेस्ट चलाए जा सकते हैं.

नीचे दी गई टेबल में, Gradle की मदद से टेस्ट चलाने के तरीके के बारे में खास जानकारी दी गई है:

पहली टेबल. Gradle की मदद से टेस्ट चलाने के अलग-अलग तरीके

यूनिट टेस्ट का टाइप	चलाने के लिए निर्देश	जांच के नतीजे की जगह
लोकल यूनिट टेस्ट	`test` टास्क को रन करें: `./gradlew test`	एचटीएमएल टेस्ट के नतीजे वाली फ़ाइलें: `path_to_your_project/module_name/build/reports/tests/` डायरेक्ट्री में मौजूद होती हैं. एक्सएमएल टेस्ट के नतीजे वाली फ़ाइलें: `path_to_your_project/module_name/build/test-results/` डायरेक्ट्री.
इंस्ट्रुमेंटेड यूनिट टेस्ट	`connectedAndroidTest` टास्क को रन करें: `./gradlew connectedAndroidTest`	एचटीएमएल टेस्ट के नतीजे वाली फ़ाइलें: `path_to_your_project/module_name/build/reports/androidTests/connected/` डायरेक्ट्री में मौजूद होती हैं. एक्सएमएल टेस्ट के नतीजे वाली फ़ाइलें: `path_to_your_project/module_name/build/outputs/androidTest-results/connected/` डायरेक्ट्री.

Gradle में टास्क के नाम के छोटे रूप इस्तेमाल किए जा सकते हैं. उदाहरण के लिए, यहां दी गई कमांड डालकर connectedAndroidTest टास्क शुरू किया जा सकता है:

./gradlew cAT

Gradle टास्क check और connectedCheck को भी चलाया जा सकता है. ये टास्क, आपके लोकल या इंस्ट्रुमेंटेड टेस्ट चलाते हैं. हालांकि, इनमें अन्य Gradle प्लगिन से जोड़े गए अन्य चेक भी शामिल होते हैं.

किसी मॉड्यूल पर टेस्ट चलाना

test और connectedAndroidTest टास्क, आपके प्रोजेक्ट के हर मॉड्यूल पर टेस्ट चलाते हैं. किसी मॉड्यूल पर टेस्ट चलाने के लिए, test या connectedAndroidTest टास्क के नाम से पहले मॉड्यूल का नाम और कोलन (:) जोड़ें. उदाहरण के लिए, यहां दी गई कमांड सिर्फ़ mylibrary मॉड्यूल के लिए इंस्ट्रुमेंटेड टेस्ट चलाती है:

./gradlew mylibrary:connectedAndroidTest

किसी बिल्ड वैरिएंट पर टेस्ट चलाना

test और connectedAndroidTest टास्क, आपके प्रोजेक्ट के हर बिल्ड वैरिएंट पर टेस्ट चलाते हैं. इस सिंटैक्स का इस्तेमाल करके, किसी खास बिल्ड वैरिएंट को टारगेट किया जा सकता है:

लोकल यूनिट टेस्ट के लिए:
```
./gradlew testVariantNameUnitTest
```
इंस्ट्रुमेंट किए गए टेस्ट के लिए:
```
./gradlew connectedVariantNameAndroidTest
```

टेस्ट के खास तरीके या क्लास चलाना

लोकल यूनिट टेस्ट चलाते समय, Gradle आपको --tests फ़्लैग का इस्तेमाल करके, खास टेस्ट को टारगेट करने की सुविधा देता है. उदाहरण के लिए, यहां दी गई कमांड सिर्फ़ बताए गए बिल्ड वैरिएंट के लिए sampleTestMethod टेस्ट चलाती है. --tests फ़्लैग इस्तेमाल करने के बारे में ज़्यादा जानने के लिए, टेस्ट फ़िल्टर करने से जुड़ा Gradle का दस्तावेज़ पढ़ें.


./gradlew testVariantNameUnitTest --tests '*.sampleTestMethod'

adb की मदद से टेस्ट चलाना

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

कमांड लाइन से टेस्ट चलाने के लिए, अपने डिवाइस या एम्युलेटर पर कमांड-लाइन शेल शुरू करने के लिए, adb shell चलाएं. उस शेल में, am कमांड का इस्तेमाल करके गतिविधि मैनेजर के साथ इंटरैक्ट किया जा सकता है. साथ ही, instrument सब-कमांड का इस्तेमाल करके टेस्ट चलाए जा सकते हैं.

शॉर्टकट के तौर पर, एक ही इनपुट लाइन पर adb shell शुरू किया जा सकता है, am instrument को कॉल किया जा सकता है, और कमांड-लाइन फ़्लैग तय किए जा सकते हैं. शेल, डिवाइस या एम्युलेटर पर खुलता है. यह आपकी जांच करता है, आउटपुट जनरेट करता है, और फिर आपके कंप्यूटर पर कमांड लाइन पर वापस आ जाता है.

am instrument की मदद से टेस्ट चलाने के लिए:

अपने मुख्य ऐप्लिकेशन और टेस्ट पैकेज को बनाएं या फिर से बनाएं.
अपने मौजूदा Android डिवाइस या एम्युलेटर पर, टेस्ट पैकेज और मुख्य ऐप्लिकेशन की Android पैकेज फ़ाइलें (APK फ़ाइलें) इंस्टॉल करें.
कमांड लाइन में यह डालें:
```
adb shell am instrument -w <test_package_name>/<runner_class>
```
यहां <test_package_name> आपके टेस्ट ऐप्लिकेशन का Android पैकेज का नाम है और <runner_class>, Android टेस्ट रनर क्लास का नाम है. Android पैकेज का नाम, आपके टेस्ट पैकेज की मेनिफ़ेस्ट फ़ाइल (AndroidManifest.xml) में, मेनिफ़ेस्ट एलिमेंट के पैकेज एट्रिब्यूट की वैल्यू होती है.

Android टेस्ट रनर क्लास आम तौर पर AndroidJUnitRunner होती है:
```
adb shell am instrument -w com.android.example/androidx.test.runner.AndroidJUnitRunner
```

जांच के नतीजे STDOUT में दिखते हैं.

am instrument flags

am instrument कमांड के साथ इस्तेमाल किए जा सकने वाले सभी फ़्लैग की सूची देखने के लिए, adb shell am help चलाएं. यहां दी गई टेबल में, कुछ अहम फ़्लैग के बारे में बताया गया है:

टेबल 2. अहम am instrument फ़्लैग

चिह्नित करें	वैल्यू	ब्यौरा
`-w`	(कोई नहीं)	इस विकल्प का इस्तेमाल करने पर, `am instrument` तब तक बंद नहीं होता, जब तक इंस्ट्रुमेंटेशन बंद नहीं हो जाता. इससे शेल तब तक खुला रहता है, जब तक टेस्ट पूरे नहीं हो जाते. इस फ़्लैग की ज़रूरत, जांच के नतीजे देखने के लिए होती है.
`-r`	(कोई नहीं)	नतीजों को रॉ फ़ॉर्मैट में दिखाता है. इस फ़्लैग का इस्तेमाल तब करें, जब आपको परफ़ॉर्मेंस मेज़रमेंट इकट्ठा करने हों, ताकि उन्हें टेस्ट के नतीजों के तौर पर फ़ॉर्मैट न किया जाए. इस फ़्लैग को, फ़्लैग `-e perf true` के साथ इस्तेमाल करने के लिए बनाया गया है. इसके बारे में, am इंस्ट्रूमेंट के विकल्प सेक्शन में बताया गया है.
`-e`	`<test_options>`	जांच के विकल्पों को की-वैल्यू पेयर के तौर पर दिखाता है. `am instrument` टूल, इन वैल्यू को तय की गई इंस्ट्रुमेंटेशन क्लास को पास करता है. इसके लिए, वह `onCreate()` मेथड का इस्तेमाल करता है. `-e <test_options>` को एक से ज़्यादा बार तय किया जा सकता है. कुंजियों और वैल्यू के बारे में am इंस्ट्रूमेंट के विकल्प सेक्शन में बताया गया है. इन की-वैल्यू पेयर का इस्तेमाल, सिर्फ़ `AndroidJUnitRunner` या `InstrumentationTestRunner` और इसकी सबक्लास के साथ किया जा सकता है. इन्हें किसी दूसरी क्लास के साथ इस्तेमाल करने पर कोई असर नहीं पड़ता.
`--no-hidden-api-checks`	(कोई नहीं)	इस विकल्प को चुनने पर, छिपे हुए एपीआई के इस्तेमाल पर लगी पाबंदियां हट जाती हैं. छुपे हुए एपीआई क्या होते हैं और इससे आपके ऐप्लिकेशन पर क्या असर पड़ सकता है, इस बारे में ज़्यादा जानकारी के लिए, SDK टूल के अलावा अन्य इंटरफ़ेस पर पाबंदियां लेख पढ़ें.

am instrument options

am instrument टूल, टेस्टिंग के विकल्पों को AndroidJUnitRunner या InstrumentationTestRunner को पास करता है. ये विकल्प, इस सिंटैक्स के साथ -e फ़्लैग का इस्तेमाल करके, कुंजी-वैल्यू पेयर के तौर पर पास किए जाते हैं:

-e <key> <value>

कुछ कुंजियों के लिए एक से ज़्यादा वैल्यू स्वीकार की जाती हैं. कॉमा लगाकर अलग की गई सूची में, एक से ज़्यादा वैल्यू दी जाती हैं. उदाहरण के लिए, AndroidJUnitRunner के इस इनवोकेशन में, package कुंजी के लिए कई वैल्यू दी गई हैं:

adb shell am instrument -w -e package com.android.test.package1,com.android.test.package2 \
> com.android.test/androidx.test.runner.AndroidJUnitRunner

यहां दी गई टेबल में, मुख्य वैल्यू की उन जोड़ियों के बारे में बताया गया है जिनका इस्तेमाल टेस्ट रनर के साथ किया जा सकता है:

तीसरी टेबल. -e फ़्लैग, की-वैल्यू पेयर को आपके टेस्ट रनर के साथ इस्तेमाल करने के लिए सेट करता है

सुरक्षा कुंजी	वैल्यू	ब्यौरा
`package`	`<Java_package_name>`	टेस्ट ऐप्लिकेशन में मौजूद किसी पैकेज के लिए, पूरी तरह क्वालिफ़ाइड Java पैकेज का नाम. इस पैकेज के नाम का इस्तेमाल करने वाली किसी भी टेस्ट केस क्लास को एक्ज़ीक्यूट किया जाता है. ध्यान दें कि यह Android पैकेज का नाम नहीं है. टेस्ट पैकेज में एक ही Android पैकेज का नाम होता है, लेकिन इसमें कई Java पैकेज हो सकते हैं.
`class`	`<class_name>`	टेस्ट केस क्लास में से किसी एक के लिए, पूरी तरह क्वालिफ़ाइड Java क्लास का नाम. सिर्फ़ इस टेस्ट केस क्लास को एक्ज़ीक्यूट किया जाता है.
`class`	`<class_name>#method name`	पूरी तरह क्वालिफ़ाइड टेस्ट केस क्लास का नाम और उसके तरीकों में से कोई एक. सिर्फ़ इस तरीके को लागू किया जाता है. क्लास के नाम और तरीके के नाम के बीच हैश मार्क (#) को ध्यान में रखें.
`func`	`true`	यह `InstrumentationTestCase` को बढ़ाने वाली सभी टेस्ट क्लास चलाता है.
`unit`	`true`	यह उन सभी टेस्ट क्लास को चलाता है जो न तो नहीं बढ़ती हैं और न ही `InstrumentationTestCase` या `PerformanceTestCase`.
`size`	[`small` \| `medium` \| `large`]	यह साइज़ के हिसाब से एनोटेट किए गए टेस्ट के तरीके को चलाता है. व्याख्याएं ये हैं: `@SmallTest`, `@MediumTest`, और `@LargeTest`.
`perf`	`true`	`PerformanceTestCase` को लागू करने वाली सभी टेस्ट क्लास चलाता है. इस विकल्प का इस्तेमाल करते समय, `-r` फ़्लैग को `am instrument` के लिए सेट करें, ताकि आउटपुट को रॉ फ़ॉर्मैट में रखा जा सके. साथ ही, इसे टेस्ट के नतीजों के तौर पर फिर से फ़ॉर्मैट न किया जाए.
`debug`	`true`	यह डीबग मोड में टेस्ट चलाता है.
`log`	`true`	यह विकल्प, तय किए गए सभी टेस्ट को लोड और लॉग करता है. हालांकि, उन्हें चलाता नहीं है. जांच की जानकारी, `STDOUT` में दिखती है. इसका इस्तेमाल, अन्य फ़िल्टर और टेस्ट स्पेसिफ़िकेशन के कॉम्बिनेशन की पुष्टि करने के लिए करें.
`emma`	`true`	यह EMMA कोड कवरेज का विश्लेषण करता है और डिवाइस पर `/data/<app_package>/coverage.ec` में आउटपुट लिखता है. फ़ाइल की जगह को बदलने के लिए, `coverageFile` कुंजी का इस्तेमाल करें. इसके बारे में यहां बताया गया है. ध्यान दें: इस विकल्प के लिए, टेस्ट ऐप्लिकेशन का EMMA-इंस्ट्रूमेंटेड बिल्ड ज़रूरी है. इसे `coverage` टारगेट की मदद से जनरेट किया जा सकता है.
`coverageFile`	`<filename>`	यह विकल्प, डिवाइस पर EMMA कवरेज फ़ाइल की डिफ़ॉल्ट जगह की जानकारी को बदलता है. इस वैल्यू को UNIX फ़ॉर्मैट में पाथ और फ़ाइल नाम के तौर पर डालें. डिफ़ॉल्ट फ़ाइल नाम के बारे में जानकारी, `emma` कुंजी की एंट्री में दी गई है.

-e फ़्लैग का इस्तेमाल करते समय, इन बातों का ध्यान रखें:

am instrument, की-वैल्यू पेयर वाले Bundle के साथ onCreate(Bundle) को शुरू करता है.
package कुंजी को class कुंजी के ऊपर प्राथमिकता दी जाती है. अगर आपने कोई पैकेज तय किया है और फिर उस पैकेज में कोई क्लास अलग से तय की है, तो Android उस पैकेज में मौजूद सभी टेस्ट चलाता है और क्लास की को अनदेखा करता है.
func कुंजी और unit कुंजी एक-दूसरे से मेल नहीं खाती हैं.

इस्तेमाल करने के उदाहरण

नीचे दिए गए सेक्शन में, टेस्ट चलाने के लिए am instrument का इस्तेमाल करने के उदाहरण दिए गए हैं. ये इस स्ट्रक्चर पर आधारित होते हैं:

टेस्ट पैकेज का Android पैकेज नाम com.android.demo.app.tests है.
इंस्ट्रुमेंट किए गए टेस्ट की दो क्लास:
- TestClass1, जिसमें टेस्ट का तरीका testMethod1 शामिल है.
- TestClass2, जिसमें टेस्ट के तरीके testMethod2 और testMethod3 शामिल हैं.
टेस्ट रनर AndroidJUnitRunner है.

पूरे टेस्ट पैकेज को चलाना

टेस्ट पैकेज में मौजूद सभी टेस्ट क्लास चलाने के लिए, यह कमांड डालें:

adb shell am instrument -w com.android.demo.app.tests/androidx.test.runner.AndroidJUnitRunner

टेस्ट केस क्लास में सभी टेस्ट चलाना

क्लास TestClass1 में सभी टेस्ट चलाने के लिए, यह डालें:

adb shell am instrument -w  \
> -e class com.android.demo.app.tests.TestClass1 \
> com.android.demo.app.tests/androidx.test.runner.AndroidJUnitRunner

टेस्ट का सबसेट चुनें

TestClass1 क्लास और TestClass2 में मौजूद testMethod3 तरीके के सभी टेस्ट चलाने के लिए, यह डालें:

adb shell am instrument -w \
> -e class com.android.demo.app.tests.TestClass1,com.android.demo.app.tests.TestClass2#testMethod3 \
> com.android.demo.app.tests/androidx.test.runner.AndroidJUnitRunner

आपको इस्तेमाल के ज़्यादा उदाहरण, AndroidJUnitRunner एपीआई के रेफ़रंस में मिल सकते हैं.

एक ही जगह पर टेस्ट की रिपोर्ट देखना

Android Gradle प्लगिन, टेस्ट रिपोर्ट के लिए एक जैसे टास्क उपलब्ध कराता है. ये टास्क, एचटीएमएल डैशबोर्ड जनरेट करते हैं. इन डैशबोर्ड में, यूनिट और इंस्ट्रुमेंटेड टेस्ट के नतीजों को मर्ज किया जाता है.

ज़रूरी शर्तें

Android Gradle प्लगिन 9.2.0-alpha07 या इसके बाद का वर्शन.

एक ही जगह पर टेस्ट रिपोर्ट जनरेट करने के लिए, इनमें से कोई एक टास्क चलाएं:

रिपोर्ट का दायरा	निर्देश	ब्यौरा	जगह की जानकारी की रिपोर्ट करना
मौजूदा मॉड्यूल	`./gradlew :module_name:createTestReport`	यह मौजूदा मॉड्यूल के लिए, यूनिफ़ाइड टेस्ट रिपोर्ट जनरेट करता है. इसमें यूनिट और इंस्ट्रुमेंटेड टेस्ट के नतीजों को मर्ज किया जाता है.	`path_to_your_project/module_name/build/reports/tests/test-report/`
मौजूदा मॉड्यूल और डिपेंडेंसी	`./gradlew :module_name:createAggregatedTestReport`	यह कुकी, मौजूदा ऐप्लिकेशन मॉड्यूल और उसकी लाइब्रेरी डिपेंडेंसी के लिए एक यूनीफ़ाइड टेस्ट रिपोर्ट जनरेट करती है.	`path_to_your_project/module_name/build/reports/tests/aggregated-test-report/`