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

इस दस्तावेज़ में, कमांड लाइन से सीधे तौर पर टेस्ट चलाने का तरीका बताया गया है. इस दस्तावेज़ में यह माना गया है कि आपको पहले से ही 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 डीबग ब्रिज (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 पैकेज का नाम, आपके टेस्ट पैकेज की मेनिफ़ेस्ट फ़ाइल (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 इंस्ट्रूमेंट के विकल्प सेक्शन में बताया गया है.
-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 कवरेज फ़ाइल की डिफ़ॉल्ट जगह बदल जाती है. इस वैल्यू को यूनिक्स फ़ॉर्मैट में पाथ और फ़ाइल नाम के तौर पर डालें. डिफ़ॉल्ट फ़ाइल नाम के बारे में, 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 Gradle प्लगिन 9.5.0-alpha05 या इसके बाद का वर्शन.

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

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