मॉड्यूल कॉन्फ़िगरेशन का पूरा स्ट्रक्चर, सामान्य ट्रेडेड एक्सएमएल कॉन्फ़िगरेशन के पैटर्न से मिलता-जुलता है. हालांकि, इसमें कुछ पाबंदियां हैं, क्योंकि ये एक सुइट के हिस्से के तौर पर चलते हैं.
अनुमति वाले टैग की सूची
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>
बिल्ड की जानकारी या डाउनलोड के बारे में क्या?
इस्तेमाल किए जा सकने वाले टैग की परिभाषा से यह गलत धारणा बन सकती है कि किसी मॉड्यूल को बिल्ड की कोई जानकारी नहीं मिलेगी. यह सही नहीं है.
बिल्ड की जानकारी, सुइट-लेवल के सेटअप से दी जाती है. इसे सुइट के सभी मॉड्यूल शेयर करेंगे. इससे, सुइट के सभी मॉड्यूल को चलाने के लिए, सुइट के लिए एक टॉप-लेवल सेटअप की अनुमति मिलती है.
उदाहरण के लिए, हर कंपैटिबिलिटी टेस्ट सुइट (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 में उपलब्ध है. अगर सीटीएस मॉड्यूल में कोई ऐसा कॉम्पोनेंट जोड़ा गया है जो पहले से मौजूद नहीं है, तो यह टेस्ट पहले से सबमिट करने में फ़ेल हो जाता है.
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: उन टेस्ट का वैरिएशन बनाएं जो APKs को इंस्टैंट ऐप्लिकेशन के तौर पर इंस्टॉल करते हैं.multi_abi: डिवाइस पर काम करने वाले हर एबीआई के लिए अलग-अलग टेस्ट बनाएं.secondary_user: उन टेस्ट का वैरिएशन बनाएं जो APKs इंस्टॉल करते हैं और दूसरे उपयोगकर्ता के तौर पर टेस्ट चलाते हैं.
परफ़ॉर्मेंस टेस्ट मॉड्यूल के लिए, मेट्रिक इकट्ठा करने और पोस्ट-प्रोसेस करने की सुविधा
परफ़ॉर्मेंस टेस्ट मॉड्यूल के लिए, मॉड्यूल-लेवल metrics_collector और
metric_post_processor का इस्तेमाल किया जा सकता है, क्योंकि ये परफ़ॉर्मेंस टेस्ट के लिए ज़रूरी हैं.
मॉड्यूल-लेवल के मेट्रिक कलेक्टर और पोस्ट-प्रोसेसर, मॉड्यूल के हिसाब से हो सकते हैं.
हमारा सुझाव है कि पोस्ट-प्रोसेसर को टॉप-लेवल और
मॉड्यूल, दोनों लेवल पर न जोड़ें.
परफ़ॉर्मेंस टेस्ट मॉड्यूल कॉन्फ़िगरेशन में, performance वैल्यू वाला test-type मेटाडेटा शामिल होना ज़रूरी है, जैसे:
xml
<option name="config-descriptor:metadata" key="test-type" value="performance" />
इसके बिना, अगर किसी टेस्ट कॉन्फ़िगरेशन में, FilePullerLogCollector या किसी metric_post_processor के अलावा कोई metric_collector शामिल हो, तो टेस्ट पहले से सबमिट नहीं हो पाएगा.
परफ़ॉर्मेंस टेस्ट मॉड्यूल कॉन्फ़िगरेशन का उदाहरण:
<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>