टेस्ट चलाना (Atest)

Atest, कमांड लाइन टूल है. इसकी मदद से, उपयोगकर्ता Android के टेस्ट, स्थानीय तौर पर बिल्ड, इंस्टॉल, और रन कर सकते हैं. इससे, Trade Federation टेस्ट हार्नेस के कमांड लाइन विकल्पों की जानकारी के बिना भी, टेस्ट को बार-बार रन किया जा सकता है. इससे टेस्ट को बार-बार रन करने में लगने वाला समय काफ़ी कम हो जाता है. इस पेज पर, Android के टेस्ट रन करने के लिए Atest का इस्तेमाल करने का तरीका बताया गया है.

Android के लिए टेस्ट लिखने के बारे में सामान्य जानकारी पाने के लिए, Android प्लैटफ़ॉर्म की टेस्टिंग देखें.

Atest के पूरे स्ट्रक्चर के बारे में जानकारी पाने के लिए, Atest के डेवलपर गाइड पर जाएं.

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

Atest में कोई सुविधा जोड़ने के लिए, Atest के डेवलपर वर्कफ़्लो को फ़ॉलो करें.

अपना एनवायरमेंट सेट अप करने का तरीका

अपना Atest एनवायरमेंट सेट अप करने के लिए, एनवायरमेंट सेट अप करना, टारगेट चुनना, और कोड बिल्ड करना में दिए गए निर्देशों का पालन करें.

बुनियादी इस्तेमाल

Atest के कमांड इस फ़ॉर्मैट में होते हैं:

atest test-to-run [optional-arguments]

ज़रूरी नहीं वाले आर्ग्युमेंट

यहां दी गई टेबल में, सबसे ज़्यादा इस्तेमाल किए जाने वाले आर्ग्युमेंट की सूची दी गई है. atest --help कमांड की मदद से, पूरी सूची देखी जा सकती है.

विकल्प लॉन्ग विकल्प ब्यौरा
-b --build टेस्ट टारगेट बिल्ड करता है. (डिफ़ॉल्ट)
-i --install डिवाइस पर टेस्ट आर्टफ़ैक्ट (एपीके) इंस्टॉल करता है. (डिफ़ॉल्ट)
-t --test टेस्ट रन करता है. (डिफ़ॉल्ट)
-s --serial चुने गए डिवाइस पर टेस्ट रन करता है. एक बार में सिर्फ़ एक डिवाइस पर टेस्ट किया जा सकता है.
-d --disable-teardown टेस्ट टियरडाउन और क्लीनअप की सुविधा बंद करता है.
--dry-run Atest को ड्राई-रन करता है. इसमें टेस्ट को बिल्ड, इंस्टॉल या रन नहीं किया जाता.
-m --rebuild-module-info module-info.json फ़ाइल को फिर से बिल्ड करता है.
-w --wait-for-debugger डीबगर के पूरा होने तक इंतज़ार करता है.
-v --verbose DEBUG लेवल की लॉगिंग दिखाता है.
--iterations टेस्ट को तब तक लूप में रन करता है, जब तक कि ज़्यादा से ज़्यादा बार रन करने की सीमा पूरी न हो जाए. (डिफ़ॉल्ट रूप से 10)
--rerun-until-failure [COUNT=10] सभी टेस्ट को तब तक बार-बार रन करता है, जब तक कोई गड़बड़ी न हो या ज़्यादा से ज़्यादा बार रन करने की सीमा पूरी न हो जाए. (डिफ़ॉल्ट रूप से 10)
--retry-any-failure [COUNT=10] फ़ेल हुए टेस्ट को तब तक बार-बार रन करता है, जब तक वे पास न हो जाएं या ज़्यादा से ज़्यादा बार रन करने की सीमा पूरी न हो जाए. (डिफ़ॉल्ट रूप से 10 )
--start-avd अपने-आप एवीडी बनाता है और वर्चुअल डिवाइस पर टेस्ट रन करता है.
--acloud-create acloud कमांड का इस्तेमाल करके, एवीडी बनाता है.
--[CUSTOM_ARGS] टेस्ट रनर के लिए कस्टम आर्ग्युमेंट तय करता है.
-a --all-abi उपलब्ध सभी डिवाइस आर्किटेक्चर के लिए टेस्ट रन करता है.
--host डिवाइस के बिना, पूरी तरह से होस्ट पर टेस्ट रन करता है.
ध्यान दें: --host के साथ, ऐसे होस्ट टेस्ट को रन नहीं किया जा सकता जिसके लिए डिवाइस की ज़रूरत हो.
--history टेस्ट के नतीजे, समय के हिसाब से क्रम में दिखाता है.
--latest-result टेस्ट का सबसे नया नतीजा दिखाता है.

-b, -i और -t के बारे में ज़्यादा जानकारी के लिए, चरण तय करना: बिल्ड करना, इंस्टॉल करना या रन करना सेक्शन देखें.

टेस्ट तय करना

टेस्ट रन करने के लिए, इनमें से किसी एक आइडेंटिफ़ायर का इस्तेमाल करके, एक या एक से ज़्यादा टेस्ट तय करें:

  • मॉड्यूल का नाम
  • मॉड्यूल:क्लास
  • क्लास का नाम
  • Tradefed इंटिग्रेशन टेस्ट
  • फ़ाइल का पाथ
  • पैकेज का नाम

एक से ज़्यादा टेस्ट के रेफ़रंस को स्पेस से अलग करें. जैसे:

atest test-identifier-1 test-identifier-2

मॉड्यूल का नाम

पूरे टेस्ट मॉड्यूल को रन करने के लिए, उसके मॉड्यूल का नाम इस्तेमाल करें. उस टेस्ट की Android.mk या Android.bp फ़ाइल में, LOCAL_MODULE या LOCAL_PACKAGE_NAME वैरिएबल में दिखने वाला नाम डालें.

उदाहरण:

atest FrameworksServicesTests
atest CtsVideoTestCases

मॉड्यूल:क्लास

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

उदाहरण:

atest CtsVideoTestCases:VideoEncoderDecoderTest
atest FrameworksServicesTests:ScreenDecorWindowTests
atest FrameworksServicesTests:com.android.server.wm.ScreenDecorWindowTests

क्लास का नाम

मॉड्यूल का नाम साफ़ तौर पर बताए बिना, किसी एक क्लास को रन करने के लिए, क्लास का नाम इस्तेमाल करें.

उदाहरण:

atest ScreenDecorWindowTests
atest VideoEncoderDecoderTest

Tradefed इंटिग्रेशन टेस्ट

TradeFed (मॉड्यूल के अलावा अन्य) में सीधे इंटिग्रेट किए गए टेस्ट रन करने के लिए, tradefed.sh list configs कमांड के आउटपुट में दिखने वाला नाम डालें. उदाहरण के लिए:

reboot.xml टेस्ट रन करने के लिए:

atest example/reboot

native-benchmark.xml टेस्ट रन करने के लिए:

atest native-benchmark

फ़ाइल का पाथ

Atest, मॉड्यूल पर आधारित टेस्ट और इंटिग्रेशन पर आधारित टेस्ट, दोनों को रन कर सकता है. इसके लिए, टेस्ट फ़ाइल या डायरेक्ट्री का पाथ डालें. यह क्लास की Java फ़ाइल का पाथ तय करके, किसी एक क्लास को भी रन कर सकता है. रेलेटिव और ऐब्सलूट, दोनों पाथ इस्तेमाल किए जा सकते हैं.

कोई मॉड्यूल रन करना

यहां दिए गए उदाहरणों में, फ़ाइल पाथ का इस्तेमाल करके, CtsVideoTestCases मॉड्यूल को रन करने के दो तरीके दिखाए गए हैं.

Android repo-root से रन करना:

atest cts/tests/video

Android repo-root/cts/tests/video से रन करना:

    atest .

कोई टेस्ट क्लास रन करना

यहां दिए गए उदाहरण में, फ़ाइल पाथ का इस्तेमाल करके, CtsVideoTestCases मॉड्यूल में मौजूद किसी खास क्लास को रन करने का तरीका दिखाया गया है.

Android repo-root से:

    atest cts/tests/video/src/android/video/cts/VideoEncoderDecoderTest.java

कोई इंटिग्रेशन टेस्ट रन करना

यहां दिए गए उदाहरण में, Android repo-root से फ़ाइल पाथ का इस्तेमाल करके, इंटिग्रेशन टेस्ट रन करने का तरीका दिखाया गया है:

    atest tools/tradefederation/contrib/res/config/example/reboot.xml

पैकेज का नाम

Atest, पैकेज के नाम से टेस्ट खोज सकता है.

उदाहरण:

    atest com.android.server.wm
    atest com.android.uibench.janktests

चरण तय करना: बिल्ड करना, इंस्टॉल करना या रन करना

यह तय करने के लिए कि कौनसे चरण रन करने हैं, -b, -i, और -t विकल्पों का इस्तेमाल करें. अगर कोई विकल्प तय नहीं किया जाता है, तो सभी चरण रन होते हैं.

  • सिर्फ़ टारगेट बिल्ड करना: atest -b test-to-run
  • सिर्फ़ टेस्ट रन करना: atest -t test-to-run
  • एपीके इंस्टॉल करना और टेस्ट रन करना: atest -it test-to-run
  • बिल्ड करना और रन करना, लेकिन इंस्टॉल नहीं करना: atest -bt test-to-run

Atest, किसी टेस्ट को क्लीनअप या टियरडाउन चरण को स्किप करने के लिए मजबूर कर सकता है. कई टेस्ट, जैसे कि सीटीएस, टेस्ट रन होने के बाद डिवाइस को साफ़ करते हैं. इसलिए, --disable-teardown पैरामीटर के बिना, -t के साथ अपने टेस्ट को फिर से रन करने की कोशिश करने पर, वह फ़ेल हो जाएगा. टेस्ट क्लीन अप चरण को स्किप करने और बार-बार टेस्ट करने के लिए, -t से पहले -d का इस्तेमाल करें.

atest -d test-to-run
atest -t test-to-run
-t

खास तरीके रन करना

Atest, टेस्ट क्लास में मौजूद खास तरीकों को रन कर सकता है. हालांकि, पूरे मॉड्यूल को बिल्ड करना पड़ता है, लेकिन इससे टेस्ट रन करने में लगने वाला समय कम हो जाता है. खास तरीकों को रन करने के लिए, क्लास की पहचान करने के लिए इस्तेमाल किए जाने वाले किसी भी तरीके (मॉड्यूल:क्लास, फ़ाइल पाथ वगैरह) का इस्तेमाल करके, क्लास की पहचान करें और तरीके का नाम जोड़ें:

atest reference-to-class#method1

एक से ज़्यादा तरीके तय करते समय, उन्हें कॉमा से अलग करें:

atest reference-to-class#method1,method2,method3

उदाहरण:

atest com.android.server.wm.ScreenDecorWindowTests#testMultipleDecors
atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange,testRemoval

यहां दिए गए दो उदाहरणों में, testFlagChange नाम के किसी एक तरीके को रन करने के पसंदीदा तरीके दिखाए गए हैं. सिर्फ़ क्लास के नाम का इस्तेमाल करने के बजाय, इन उदाहरणों का इस्तेमाल करना बेहतर है. इसकी वजह यह है कि मॉड्यूल या Java फ़ाइल की जगह तय करने से, Atest को टेस्ट ढूंढने में काफ़ी कम समय लगता है.

मॉड्यूल:क्लास का इस्तेमाल करना:

atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange

Android repo-root से:

atest frameworks/base/services/tests/wmtests/src/com/android/server/wm/ScreenDecorWindowTests.java#testFlagChange

अलग-अलग क्लास और मॉड्यूल से, एक से ज़्यादा तरीके रन किए जा सकते हैं:

atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange,testRemoval ScreenDecorWindowTests#testMultipleDecors

एक से ज़्यादा क्लास रन करना

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

एक ही मॉड्यूल में दो क्लास रन करने के लिए:

atest FrameworksServicesTests:ScreenDecorWindowTests FrameworksServicesTests:DimmerTests

अलग-अलग मॉड्यूल में दो क्लास रन करने के लिए:

atest FrameworksServicesTests:ScreenDecorWindowTests CtsVideoTestCases:VideoEncoderDecoderTest

GTest बाइनरी रन करना

Atest, GTest बाइनरी रन कर सकता है. उपलब्ध सभी डिवाइस आर्किटेक्चर के लिए इन टेस्ट को रन करने के लिए, -a का इस्तेमाल करें. इस उदाहरण में, ये आर्किटेक्चर armeabi-v7a (ARM 32-बिट) और arm64-v8a (ARM 64-बिट) हैं.

इनपुट टेस्ट का उदाहरण:

atest -a libinput_tests inputflinger_tests

रन करने के लिए, कोई खास GTest बाइनरी चुनने के लिए, टेस्ट का नाम तय करने के लिए कॉलन (:) और किसी एक तरीके को तय करने के लिए हैशटैग (#) का इस्तेमाल करें.

उदाहरण के लिए, टेस्ट की इस परिभाषा के लिए: 

TEST_F(InputDispatcherTest, InjectInputEvent_ValidatesKeyEvents)

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

atest inputflinger_tests:InputDispatcherTest

या किसी एक टेस्ट को रन करने के लिए, यह कमांड रन करें: 

atest inputflinger_tests:InputDispatcherTest#InjectInputEvent_ValidatesKeyEvents

TEST_MAPPING में टेस्ट रन करना

Atest, TEST_MAPPING फ़ाइलों में टेस्ट रन कर सकता है.

सबमिट करने से पहले किए जाने वाले टेस्ट, अपने-आप रन करना

मौजूदा और पैरंट डायरेक्ट्री में मौजूद TEST_MAPPING फ़ाइलों में, सबमिट करने से पहले किए जाने वाले टेस्ट रन करना:

atest

/path/to/project और उसकी पैरंट डायरेक्ट्री में मौजूद TEST_MAPPING फ़ाइलों में, सबमिट करने से पहले किए जाने वाले टेस्ट रन करना:

atest --test-mapping /path/to/project

तय किया गया टेस्ट ग्रुप रन करना

उपलब्ध टेस्ट ग्रुप ये हैं: presubmit(डिफ़ॉल्ट), postsubmit, mainline-presubmit, और all.

मौजूदा और पैरंट डायरेक्ट्री में मौजूद TEST_MAPPING फ़ाइलों में, सबमिट करने के बाद किए जाने वाले टेस्ट रन करना:

atest :postsubmit

TEST_MAPPING फ़ाइलों में मौजूद सभी ग्रुप के टेस्ट रन करना:

atest :all

/path/to/project और उसकी पैरंट डायरेक्ट्री में मौजूद TEST_MAPPING फ़ाइलों में, सबमिट करने के बाद किए जाने वाले टेस्ट रन करना:

atest --test-mapping /path/to/project:postsubmit

/path/to/project और उसकी पैरंट डायरेक्ट्री में मौजूद TEST_MAPPING फ़ाइलों में, मेनलाइन टेस्ट रन करना:

atest --test-mapping /path/to/project:mainline-presubmit

सबडायरेक्ट्री में टेस्ट रन करना

डिफ़ॉल्ट रूप से, Atest सिर्फ़ TEST_MAPPING फ़ाइलों में ऊपर की ओर (मौजूदा या दी गई डायरेक्ट्री से उसकी पैरंट डायरेक्ट्री तक) टेस्ट खोजता है. अगर आपको सबडायरेक्ट्री में मौजूद TEST_MAPPING फ़ाइलों में भी टेस्ट रन करने हैं, तो --include-subdirs का इस्तेमाल करें. इससे Atest उन टेस्ट को भी शामिल करेगा:

atest --include-subdirs /path/to/project

बार-बार टेस्ट रन करना

--iterations आर्ग्युमेंट पास करके, टेस्ट को बार-बार रन करें. चाहे टेस्ट पास हो या फ़ेल, Atest उसे तब तक दोहराएगा, जब तक कि ज़्यादा से ज़्यादा बार रन करने की सीमा पूरी न हो जाए.

उदाहरण:

डिफ़ॉल्ट रूप से, Atest 10 बार टेस्ट रन करता है. बार-बार टेस्ट रन करने की संख्या, पॉज़िटिव इंटिजर होनी चाहिए.

atest test-to-run --iterations
atest test-to-run --iterations 5

इन तरीकों से, फ़्लेकी टेस्ट का पता लगाना आसान हो जाता है:

पहला तरीका: सभी टेस्ट को तब तक रन करें, जब तक कोई गड़बड़ी न हो या ज़्यादा से ज़्यादा बार रन करने की सीमा पूरी न हो जाए.

  • गड़बड़ी होने पर या (डिफ़ॉल्ट रूप से) 10वीं बार टेस्ट रन होने पर, टेस्ट रन करना बंद करें. 
    atest test-to-run --rerun-until-failure
  • गड़बड़ी होने पर या 100वीं बार टेस्ट रन होने पर, टेस्ट रन करना बंद करें. 
    atest test-to-run --rerun-until-failure 100

दूसरा तरीका: सिर्फ़ फ़ेल हुए टेस्ट को तब तक रन करें, जब तक वे पास न हो जाएं या ज़्यादा से ज़्यादा बार रन करने की सीमा पूरी न हो जाए.

  • मान लें कि test-to-run में एक से ज़्यादा टेस्ट केस हैं और उनमें से एक टेस्ट फ़ेल हो जाता है. सिर्फ़ फ़ेल हुए टेस्ट को (डिफ़ॉल्ट रूप से) 10 बार या तब तक रन करें, जब तक वह पास न हो जाए. 
    atest test-to-run --retry-any-failure
  • फ़ेल हुआ टेस्ट पास होने या 100वीं बार रन होने पर, उसे रन करना बंद करें. 
    atest test-to-run --retry-any-failure 100

एवीडी पर टेस्ट रन करना

Atest, नए बनाए गए एवीडी पर टेस्ट रन कर सकता है. एवीडी और बिल्ड आर्टफ़ैक्ट बनाने के लिए, acloud create रन करें. इसके बाद, अपने टेस्ट रन करने के लिए, यहां दिए गए उदाहरणों का इस्तेमाल करें.

एवीडी शुरू करना और उस पर टेस्ट रन करना:

acloud create --local-instance --local-image && atest test-to-run

टेस्ट रन के हिस्से के तौर पर, एवीडी शुरू करना:

atest test-to-run --acloud-create "--local-instance --local-image"

ज़्यादा जानकारी के लिए, acloud create --help रन करें.

मॉड्यूल को विकल्प पास करना

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

atest test-to-run -- [CUSTOM_ARGS]

टेस्ट कॉन्फ़िगरेशन फ़ाइल में तय किए गए, टारगेट प्रिपेरर या टेस्ट रनर को टेस्ट मॉड्यूल के विकल्प पास करना:

atest test-to-run -- --module-arg module-name:option-name:option-value
atest GtsPermissionTestCases -- --module-arg GtsPermissionTestCases:ignore-business-logic-failure:true

किसी रनर टाइप या क्लास को विकल्प पास करना:

atest test-to-run -- --test-arg test-class:option-name:option-value
atest CtsVideoTestCases -- --test-arg com.android.tradefed.testtype.JarHosttest:collect-tests-only:true

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