कुछ टेस्ट मॉड्यूल के लिए, सेटअप और बंद करने के ऐसे चरणों की ज़रूरत पड़ सकती है जिन्हें टेस्ट केस में शामिल नहीं किया जा सकता. इसके सामान्य उदाहरणों में ये शामिल हो सकते हैं:
- टेस्ट APK के अलावा, अन्य APK इंस्टॉल करें
- डिवाइस पर कुछ फ़ाइलें पुश करें
- निर्देश चलाएं (जैसे, adb shell pm ...)
पहले, कॉम्पोनेंट टीमें आम तौर पर इस तरह के टास्क को पूरा करने के लिए, होस्ट साइड टेस्ट लिखती थीं. इसके लिए, Trade Federation harness को समझना ज़रूरी होता है. साथ ही, इससे आम तौर पर टेस्ट मॉड्यूल की जटिलता बढ़ जाती है.
सीटीएस से उधार लेकर, हमने इस तरह के टास्क को पूरा करने के लिए, टेस्ट मॉड्यूल कॉन्फ़िगरेशन का कॉन्सेप्ट पेश किया है. ऊपर दी गई सामान्य टास्क की सूची को, कॉन्फ़िगरेशन की कुछ लाइनों की मदद से पूरा किया जा सकता है. ज़्यादा से ज़्यादा फ़्लेक्सिबिलिटी के लिए, ITargetPreparer या ITargetCleaner के तौर पर तय किए गए अपने टारगेट प्रिपरेर को भी लागू किया जा सकता है. साथ ही, उन्हें अपने टेस्ट मॉड्यूल कॉन्फ़िगरेशन में इस्तेमाल करने के लिए कॉन्फ़िगर किया जा सकता है.
टेस्ट मॉड्यूल के लिए टेस्ट मॉड्यूल कॉन्फ़िगरेशन, एक ज़रूरी एक्सएमएल फ़ाइल होती है. इसे टॉप लेवल के मॉड्यूल सोर्स फ़ोल्डर में जोड़ा जाता है. इसका नाम ‘AndroidTest.xml’ होता है. एक्सएमएल, Trade Federation टेस्ट ऑटोमेशन हार्नेस के लिए इस्तेमाल की जाने वाली कॉन्फ़िगरेशन फ़ाइल के फ़ॉर्मैट में होता है. फ़िलहाल, टेस्ट मॉड्यूल कॉन्फ़िगरेशन के ज़रिए मैनेज किए जाने वाले मुख्य टैग, “target_preparer” और "test" टैग हैं.
टैक्स फ़ाइल तैयार करने वाले लोगों या कंपनियों को टारगेट करना
“target_preparer” टैग, जैसा कि नाम से पता चलता है, एक टारगेट प्रिपेयरर (ITargetPreparer देखें) को तय करता है. यह एक सेटअप करने का तरीका उपलब्ध कराता है. इसे टेस्ट मॉड्यूल के एक्ज़ीक्यूट होने से पहले कॉल किया जाता है, ताकि टेस्टिंग की जा सके. अगर “target_preparer” टैग में रेफ़र की गई क्लास, ITargetCleaner को भी लागू करती है, तो टेस्ट मॉड्यूल के खत्म होने के बाद, इसके टियरडाउन तरीके को लागू किया जाएगा.
कॉमन मॉड्यूल के बिल्ट-इन कॉन्फ़िगरेशन का इस्तेमाल करने के लिए, अपने टेस्ट मॉड्यूल के टॉप लेवल फ़ोल्डर में ‘AndroidTest.xml’ नाम की नई फ़ाइल जोड़ें. इसके बाद, इसमें यह कॉन्टेंट डालें:
<?xml version="1.0" encoding="utf-8"?>
<!-- [insert standard AOSP copyright here] -->
<configuration description="Test module config for Foo">
<!-- insert options here -->
</configuration>
उदाहरण के लिए, हम ऊपर दी गई “insert” टिप्पणी में, ये विकल्प टैग जोड़ सकते हैं:
<target_preparer class="com.android.tradefed.targetprep.RunCommandTargetPreparer">
<option name="run-command" value="settings put secure accessibility_enabled 1" />
<option name="teardown-command" value="settings put secure accessibility_enabled 0" />
</target_preparer>
इन विकल्पों से, टेस्ट हार्नेस को इस तरह कॉन्फ़िगर किया जाएगा:
- टेस्ट मॉड्यूल शुरू होने से पहले, डिवाइस पर “settings put secure accessibility_enabled 1” शेल कमांड चलाएं
- टेस्ट मॉड्यूल पूरा होने के बाद, शेल कमांड “settings put secure accessibility_enabled 0” को लागू करें
इस उदाहरण में, टेस्ट मॉड्यूल के एक्ज़ीक्यूशन से पहले और बाद में, सुलभता की सुविधा को चालू/बंद किया गया है. आसान उदाहरण के साथ यह दिखाना ज़रूरी है कि “option” टैग का इस्तेमाल कैसे किया जाता है. ऊपर दिखाए गए उदाहरण में, टैग में दो एट्रिब्यूट हो सकते हैं: नाम और वैल्यू. name एट्रिब्यूट में, तैयारी करने वाले व्यक्ति या कंपनी की ओर से दिए गए विकल्पों में से किसी एक का रेफ़रंस होना चाहिए.
वैल्यू फ़ील्ड का असल मकसद, विकल्प तैयार करने वाले व्यक्ति पर निर्भर करता है. यह स्ट्रिंग, संख्या, बूलियन या फ़ाइल पाथ भी हो सकता है. यहां टारगेट तैयार करने वाले तीन सामान्य लोगों के बारे में खास जानकारी दी गई है:
क्लास का नाम: PushFilePreparer
- short name: push-file
- function: pushes arbitrary files under test case folder into destination on device
- notes:
- यह फ़ोल्डर से फ़ोल्डर या फ़ाइल से फ़ाइल में डेटा ट्रांसफ़र कर सकता है; इसका मतलब है कि डिवाइस पर किसी फ़ोल्डर में मौजूद फ़ाइल को ट्रांसफ़र नहीं किया जा सकता: आपको उस फ़ोल्डर में मौजूद फ़ाइल के नाम की जानकारी भी देनी होगी
- options:
- push-file: यह पुश-स्पेक है. इसमें डिवाइस पर पुश की जाने वाली लोकल फ़ाइल का पाथ बताया जाता है. इसे दोहराया जा सकता है. अगर एक ही रिमोट पाथ पर कई फ़ाइलें पुश करने के लिए कॉन्फ़िगर की गई हैं, तो सबसे नई फ़ाइल पुश की जाएगी.
- push: (deprecated) पुश-स्पेक, जिसे इस फ़ॉर्मैट में रखा जाता है:
'
/path/to/srcfile.txt->/path/to/destfile.txt' या '/path/to/srcfile.txt->/path/to/destdir/'. इसे दोहराया जा सकता है. यह पाथ, टेस्ट मॉड्यूल डायरेक्ट्री या आउट डायरेक्ट्री के हिसाब से हो सकता है. - post-push: यह एक ऐसा निर्देश है जिसे सभी पुश पूरे होने के बाद, डिवाइस पर (`
adb shell <your command>`) चलाया जाता है. अनुमतियों के लिए chmod का इस्तेमाल करना, सामान्य इस्तेमाल का उदाहरण है
क्लास का नाम: InstallApkSetup
- छोटा नाम:install-apk
- function: pushes arbitrary apk files under into destination on device
- options:
- test-file-name: डिवाइस पर इंस्टॉल किए जाने वाले APK का नाम.
- install-arg: pm install कमांड को पास किए जाने वाले अतिरिक्त आर्ग्युमेंट.इनमें डैश भी शामिल है. उदाहरण के लिए, “-d". दोहराया जा सकता है
क्लास का नाम: RunCommandTargetPreparer
- छोटा नाम: run-command
- function: यह फ़ंक्शन, टेस्ट मॉड्यूल के एक्ज़ीक्यूशन से पहले या बाद में, शेल कमांड को एक्ज़ीक्यूट करता है
- options:
- run-command:adb शेल कमांड को चलाने के लिए. दोहराया जा सकता है
- teardown-command:यह teardown फ़ेज़ के दौरान चलाने के लिए, adb shell कमांड है. दोहराया जा सकता है
टेस्ट क्लास
टेस्ट क्लास, Trade Federation क्लास होती है. इसका इस्तेमाल टेस्ट को एक्ज़ीक्यूट करने के लिए किया जाता है.
<test class="com.android.tradefed.testtype.AndroidJUnitTest">
<option name="package" value="android.test.example.helloworld"/>
<option name="runner" value="android.support.test.runner.AndroidJUnitRunner"/>
</test>
यहां तीन सामान्य टेस्ट क्लास दी गई हैं:
क्लास का नाम: GTest
- छोटा नाम: gtest
- फ़ंक्शन: यह एक ऐसा टेस्ट है जो दिए गए डिवाइस पर नेटिव टेस्ट पैकेज चलाता है.
- options:
- native-test-device-path:डिवाइस पर वह पाथ जहां नेटिव टेस्ट मौजूद हैं.
क्लास का नाम: InstrumentationTest
- short name: इंस्ट्रूमेंटेशन
- फ़ंक्शन: यह टेस्ट, दिए गए डिवाइस पर इंस्ट्रुमेंटेशन टेस्ट पैकेज चलाता है
- options:
- package:यह Android टेस्ट ऐप्लिकेशन के मेनिफ़ेस्ट पैकेज का नाम है, जिसे चलाना है.
- class:टेस्ट चलाने के लिए टेस्ट क्लास का नाम.
- method:टेस्ट करने के तरीके का नाम.
क्लास का नाम: AndroidJUnitTest
- function: A Test that runs an instrumentation test package on given device using the android.support.test.runner.AndroidJUnitRunner This is the main way to execute an instrumentation test.