मॉड्यूल कॉन्फ़िगरेशन का पूरा स्ट्रक्चर, Tradefed के सामान्य एक्सएमएल कॉन्फ़िगरेशन के पैटर्न जैसा ही होता है. हालांकि, कुछ पाबंदियां होती हैं, क्योंकि ये सुइट के हिस्से के तौर पर चलते हैं.
अनुमति वाले टैग की सूची
AndroidTest.xml या मॉड्यूल कॉन्फ़िगरेशन में सिर्फ़ ये एक्सएमएल टैग शामिल हो सकते हैं: target_preparer, multi_target_preparer, test, और metrics_collector.
हालांकि, यह सूची सीमित लगती है, लेकिन इसकी मदद से टेस्ट मॉड्यूल सेटअप करने की ज़रूरतों और टेस्ट को चलाने के बारे में सटीक जानकारी दी जा सकती है.
ध्यान दें: अगर आपको अलग-अलग टैग के बारे में फिर से जानकारी चाहिए, तो Tradefed XML कॉन्फ़िगरेशन देखें.
अगर मॉड्यूल कॉन्फ़िगरेशन के अंदर से 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 को इंस्टॉल करना ज़रूरी है. साथ ही, यह 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 कॉम्पोनेंट के बारे में बताता है जिसे मॉड्यूल टेस्ट करना चाहता है. इसका टेस्ट के एक्ज़ीक्यूशन पर कोई सीधा असर नहीं पड़ता. इसका इस्तेमाल मुख्य रूप से संगठन के कामों के लिए किया जाता है.
सीटीएस के लिए, अनुमति वाले कॉम्पोनेंट की अपडेट की गई सूची CtsConfigLoadingTest में उपलब्ध है. अगर किसी ऐसे कॉम्पोनेंट को सीटीएस मॉड्यूल में जोड़ा जाता है जो मौजूद नहीं है, तो यह टेस्ट प्रीसबमिट में फ़ेल हो जाता है.
module-metadata-include-filter और module-metadata-exclude-filter का इस्तेमाल करके, कॉम्पोनेंट के आधार पर सुइट रन को फ़िल्टर किया जा सकता है.
उदाहरण:
--module-metadata-include-filter component framework
इस उदाहरण में, सिर्फ़ framework
component के साथ एनोटेट किए गए टेस्ट मॉड्यूल को चलाया जाता है.
पैरामीटर
parameter मेटाडेटा में जानकारी होती है और इससे टेस्ट के एक्ज़ीक्यूशन पर असर पड़ता है. इससे पता चलता है कि टेस्ट मॉड्यूल, Android के किस मोड पर लागू होता है.
इस मामले में, modes को Android के हाई लेवल मोड तक सीमित रखा जाता है. जैसे, instant apps, secondary users या different abis.
सूट रन के दौरान, अगर मोड टेस्ट पर लागू होता है, तो मोड के आधार पर टेस्ट मॉड्यूल के कई वर्शन बनाए जाते हैं. हर वैरिएंट में एक जैसे टेस्ट अलग-अलग मोड में किए जाते हैं.
instant_app: टेस्ट का ऐसा वर्शन बनाएं जो APK को झटपट ऐप्लिकेशन के तौर पर इंस्टॉल करता हो.multi_abi: डिवाइस पर काम करने वाले हर एबीआई के लिए, टेस्ट का एक वैरिएंट बनाएं.secondary_user: जांच का ऐसा वर्शन बनाएं जो APK इंस्टॉल करता हो और सेकंडरी उपयोगकर्ता के तौर पर जांच करता हो.
परफ़ॉर्मेंस की जांच करने वाले मॉड्यूल के लिए, मेट्रिक इकट्ठा करना और पोस्ट-प्रोसेसिंग करना
परफ़ॉर्मेंस टेस्ट मॉड्यूल के लिए, मॉड्यूल-लेवल पर metrics_collector और metric_post_processor की अनुमति है, क्योंकि ये परफ़ॉर्मेंस टेस्ट के लिए ज़रूरी हैं.
मॉड्यूल-लेवल के मेट्रिक कलेक्टर और पोस्ट-प्रोसेसर, मॉड्यूल के हिसाब से तय किए जा सकते हैं.
हमारा सुझाव है कि टॉप-लेवल और मॉड्यूल-लेवल, दोनों पर पोस्ट-प्रोसेसर तय न करें.
परफ़ॉर्मेंस टेस्ट मॉड्यूल कॉन्फ़िगरेशन में, test-type मेटाडेटा शामिल होना चाहिए. इसकी वैल्यू performance होनी चाहिए. जैसे:
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>