मॉड्यूल कॉन्फ़िगरेशन का पूरा स्ट्रक्चर, Tradefed के सामान्य एक्सएमएल कॉन्फ़िगरेशन जैसा ही होता है. हालांकि, इस पर कुछ पाबंदियां लागू होती हैं, क्योंकि ये सुइट के हिस्से के तौर पर काम करते हैं.
अनुमति वाले टैग की सूची
AndroidTest.xml या मॉड्यूल कॉन्फ़िगरेशन में सिर्फ़ ये एक्सएमएल टैग शामिल किए जा सकते हैं: target_preparer, multi_target_preparer, test, और metrics_collector.
भले ही, यह सूची पाबंदियों वाली लगे, लेकिन इससे आपको टेस्ट मॉड्यूल के सेटअप की ज़रूरतों और टेस्ट को सटीक तरीके से तय करने में मदद मिलती है.
ध्यान दें: अलग-अलग टैग के बारे में जानने के लिए, Tradefed का एक्सएमएल कॉन्फ़िगरेशन देखें.
build_provider या result_reporter जैसे ऑब्जेक्ट को मॉड्यूल कॉन्फ़िगरेशन के अंदर से चलाने की कोशिश करने पर, ConfigurationException गड़बड़ी दिखेगी. ऐसा इसलिए किया जाता है, ताकि इन ऑब्जेक्ट से मॉड्यूल के अंदर कोई टास्क पूरा करने की उम्मीद न की जाए.
मॉड्यूल कॉन्फ़िगरेशन का उदाहरण
<configuration description="Config for CTS Gesture test cases">
<option name="test-suite-tag" value="cts" />
<target_preparer class="com.android.tradefed.targetprep.suite.SuiteApkInstaller">
<option name="cleanup-apks" value="true" />
<option name="test-file-name" value="CtsGestureTestCases.apk" />
</target_preparer>
<test class="com.android.tradefed.testtype.AndroidJUnitTest" >
<option name="package" value="android.gesture.cts" />
<option name="runtime-hint" value="10m50s" />
</test>
</configuration>
इस कॉन्फ़िगरेशन में, ऐसे टेस्ट के बारे में बताया गया है जिसके लिए CtsGestureTestCases.apk इंस्टॉल करना ज़रूरी है. साथ ही, यह android.gesture.cts पैकेज के ख़िलाफ़ इंस्ट्रूमेंटेशन चलाएगा.
शामिल करने वाले टैग <include> और <template-include>
मॉड्यूल कॉन्फ़िगरेशन में <include> और <template-include> का इस्तेमाल करने से बचने का सुझाव दिया जाता है. इस बात की कोई गारंटी नहीं है कि ये उम्मीद के मुताबिक काम करेंगे.
metrics_collector टैग के लिए खास मामला
metrics_collector टैग का इस्तेमाल किया जा सकता है. हालांकि, इसे
FilePullerLogCollector
क्लास तक सीमित रखा गया है, ताकि
मॉड्यूल के लिए किसी फ़ाइल या डायरेक्ट्री को पुल और लॉग किया जा सके. यह तब काम का होता है, जब आपने लॉग किसी खास जगह पर छोड़े हों और उन्हें अपने-आप वापस पाना हो.
कॉन्फ़िगरेशन का उदाहरण:
<configuration description="Config for CTS UI Rendering test cases">
<target_preparer class="com.android.tradefed.targetprep.suite.SuiteApkInstaller">
<option name="cleanup-apks" value="true" />
<option name="test-file-name" value="CtsUiRenderingTestCases.apk" />
</target_preparer>
<test class="com.android.tradefed.testtype.AndroidJUnitTest" >
<option name="package" value="android.uirendering.cts" />
<option name="runtime-hint" value="11m55s" />
<option name="runner" value="android.uirendering.cts.runner.UiRenderingRunner" />
<option name="isolated-storage" value="false" />
</test>
<!-- Collect the files in the dump directory for debugging -->
<metrics_collector class="com.android.tradefed.device.metric.FilePullerLogCollector">
<option name="directory-keys" value="/sdcard/UiRenderingCaptures" />
<option name="collect-on-run-ended-only" value="true" />
</metrics_collector>
</configuration>
बिल्ड की जानकारी या डाउनलोड के बारे में क्या कहा जा सकता है?
अनुमति वाले टैग की परिभाषा से यह गलत इंप्रेशन मिल सकता है कि किसी मॉड्यूल को बिल्ड की कोई जानकारी नहीं मिलेगी. यह सही नहीं है.
बिल्ड की जानकारी, सुइट-लेवल के सेटअप से मिलती है. इसे सुइट के सभी मॉड्यूल शेयर करेंगे. इससे सुइट के सभी मॉड्यूल को चलाने के लिए, सुइट के लिए एक टॉप-लेवल सेटअप किया जा सकता है.
उदाहरण के लिए, हर
Compatibility Test Suite (CTS)
मॉड्यूल, डिवाइस की जानकारी, टाइप वगैरह के बारे में अलग-अलग क्वेरी करने के बजाय, CTS
सुइट-लेवल का सेटअप (cts.xml) ऐसा एक बार करता है. इसके बाद, हर मॉड्यूल को वह
जानकारी मिलती है, अगर वे इसकी मांग करते हैं.
किसी मॉड्यूल में मौजूद ऑब्जेक्ट को बिल्ड की जानकारी पाने के लिए, उन्हें वही करना होगा जो Tradefed के सामान्य कॉन्फ़िगरेशन में करना होता है: IBuildInfo पाने के लिए, IBuildReceiver इंटरफ़ेस लागू करना होगा. ज़्यादा जानकारी के लिए,
डिवाइस के साथ टेस्टिंग करना
देखें.
मेटाडेटा फ़ील्ड
ज़्यादातर टेस्ट मॉड्यूल में, metadata की कुछ खास जानकारी शामिल होती है. हर जानकारी का अपना एक मकसद होता है.
उदाहरण:
<option name="config-descriptor:metadata" key="component" value="framework" />
<option name="config-descriptor:metadata" key="parameter" value="instant_app" />
<option name="config-descriptor:metadata" key="parameter" value="multi_abi" />
<option name="config-descriptor:metadata" key="parameter" value="secondary_user" />
कॉम्पोनेंट
component मेटाडेटा, उस सामान्य Android कॉम्पोनेंट के बारे में बताता है जिसे मॉड्यूल टेस्ट करना चाहता है. इसका टेस्ट के एक्ज़ीक्यूशन पर कोई सीधा असर नहीं पड़ता. इसका इस्तेमाल मुख्य रूप से संगठन के मकसद से किया जाता है.
CTS के लिए अनुमति वाले कॉम्पोनेंट की अप-टू-डेट सूची, CtsConfigLoadingTest में उपलब्ध है. अगर CTS मॉड्यूल में कोई ऐसा कॉम्पोनेंट जोड़ा जाता है जो मौजूद नहीं है, तो यह टेस्ट, सबमिट करने से पहले ही फ़ेल हो जाता है.
module-metadata-include-filter और module-metadata-exclude-filter का इस्तेमाल करके, कॉम्पोनेंट के आधार पर सुइट रन को फ़िल्टर किया जा सकता है.
उदाहरण:
--module-metadata-include-filter component framework
इस उदाहरण में, सिर्फ़ framework कॉम्पोनेंट के साथ एनोटेट किया गया टेस्ट मॉड्यूल चलता है.
पैरामीटर
parameter मेटाडेटा, जानकारी देने वाला होता है और इसका असर टेस्ट के एक्ज़ीक्यूशन पर पड़ता है. इससे यह तय होता है कि टेस्ट मॉड्यूल, Android के किस मोड पर लागू होता है.
इस मामले में, मोड को Android के हाई लेवल मोड तक सीमित रखा जाता है. जैसे, instant apps, secondary users या different abis.
सुइट रन के दौरान, अगर मोड टेस्ट पर लागू होता है, तो मोड के आधार पर टेस्ट मॉड्यूल के कई वैरिएंट बनाए जाते हैं. हर वैरिएंट, एक जैसे टेस्ट चलाता है, लेकिन अलग-अलग मोड में.
instant_app: ऐसे टेस्ट का वैरिएंट बनाएं जो APK को इंस्टैंट ऐप्लिकेशन के तौर पर इंस्टॉल करते हैं.multi_abi: डिवाइस के साथ काम करने वाले हर ABI के लिए, टेस्ट का वैरिएंट बनाएं.secondary_user: ऐसे टेस्ट का वैरिएंट बनाएं जो APK इंस्टॉल करते हैं और सेकंडरी यूज़र के तौर पर टेस्ट चलाते हैं.
परफ़ॉर्मेंस टेस्ट मॉड्यूल के लिए मेट्रिक इकट्ठा करना और पोस्ट-प्रोसेसिंग करना
परफ़ॉर्मेंस टेस्ट मॉड्यूल के लिए, मॉड्यूल-लेवल के metrics_collector और metric_post_processor का इस्तेमाल किया जा सकता है, क्योंकि ये परफ़ॉर्मेंस टेस्ट के लिए ज़रूरी हैं.
मॉड्यूल-लेवल के मेट्रिक कलेक्टर और पोस्ट-प्रोसेसर, मॉड्यूल के हिसाब से तय किए जा सकते हैं.
टॉप-लेवल और मॉड्यूल-लेवल, दोनों पर पोस्ट-प्रोसेसर तय करने का सुझाव नहीं दिया जाता.
परफ़ॉर्मेंस टेस्ट मॉड्यूल के कॉन्फ़िगरेशन में, test-type मेटाडेटा
को performance वैल्यू के साथ शामिल करना ज़रूरी है. जैसे:
xml
<option name="config-descriptor:metadata" key="test-type" value="performance" />
इसके बिना, अगर किसी टेस्ट कॉन्फ़िगरेशन में metric_collector के अलावा कोई दूसरा
FilePullerLogCollector या कोई metric_post_processor शामिल है, तो टेस्ट
सबमिट करने से पहले ही फ़ेल हो जाता है.
परफ़ॉर्मेंस टेस्ट मॉड्यूल के कॉन्फ़िगरेशन का उदाहरण:
<configuration description="Runs sample performance test.">
<!-- Declare as a performance test module -->
<option name="config-descriptor:metadata" key="test-type" value="performance" />
<option name="test-tag" value="hello-world-performance-test" />
<test class="com.android.tradefed.testtype.HostTest" >
<option name="class" value="android.test.example.helloworldperformance.HelloWorldPerformanceTest" />
</test>
<!-- Add module-level post processor MetricFilePostProcessor -->
<metric_post_processor class="com.android.tradefed.postprocessor.MetricFilePostProcessor">
<option name="aggregate-similar-tests" value="true" />
<option name="enable-per-test-log" value="false" />
</metric_post_processor>
</configuration>