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

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

इस पेज पर बताए गए कमांड-लाइन टूल और Gradle टास्क, यूज़र इंटरफ़ेस (यूआई) टूलकिट से अलग हैं. अगर आपको Compose के लिए यूज़र इंटरफ़ेस (यूआई) टेस्ट लिखने हैं, तो अपने Compose लेआउट की जांच करना लेख पढ़ें. टेस्ट लिखने के बाद, इस गाइड को पढ़कर उन्हें अपने टर्मिनल या रिमोट कंटीन्यूअस इंटिग्रेशन एनवायरमेंट से चलाएं.

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

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

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

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

  1. अपने मुख्य ऐप्लिकेशन और टेस्ट पैकेज को बनाएं या फिर से बनाएं.
  2. अपने मौजूदा Android डिवाइस या एम्युलेटर पर, जांच वाले पैकेज और मुख्य ऐप्लिकेशन की Android पैकेज फ़ाइलें (APK फ़ाइलें) इंस्टॉल करें.

  3. कमांड लाइन पर यह डालें:

    adb shell am instrument -w <test_package_name>/<runner_class>

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

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_name>#method name पूरी तरह क्वालिफ़ाइड टेस्ट केस क्लास का नाम और उसका कोई एक तरीका. सिर्फ़ इस तरीके को लागू किया जाता है. क्लास के नाम और तरीके के नाम के बीच हैश मार्क (#) को ध्यान में रखें.
size [small | medium | large] यह साइज़ के हिसाब से एनोटेट किए गए टेस्ट के तरीके को चलाता है. व्याख्याएं ये हैं: @SmallTest, @MediumTest, और @LargeTest.
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 क्लास और testMethod3 तरीके में मौजूद सभी टेस्ट चलाने के लिए, TestClass2 में यह डालें:

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.experimental.reportAggregationSupport=true पर सेट करें.

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

  • 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/