यह टेस्ट मैपिंग के बारे में कम शब्दों में बताया गया है. साथ ही, इसमें यह भी बताया गया है कि Android ओपन सोर्स प्रोजेक्ट (एओएसपी) में टेस्ट कॉन्फ़िगर करना कैसे शुरू किया जाता है.
टेस्ट मैपिंग के बारे में जानकारी
टेस्ट मैपिंग, Gerrit पर आधारित एक तरीका है. इसकी मदद से डेवलपर, सीधे Android सोर्स ट्री में प्री-सबमिट और पोस्ट-सबमिट टेस्ट नियम बना सकते हैं.
साथ ही, ब्रांच और डिवाइसों से जुड़े फ़ैसलों को टेस्ट इन्फ़्रास्ट्रक्चर पर टेस्ट करने के लिए छोड़ देते हैं.
टेस्ट मैपिंग की परिभाषाएं, TEST_MAPPING नाम की JSON फ़ाइलें होती हैं. इन्हें किसी भी सोर्स डायरेक्ट्री में रखा जा सकता है.
Atest में TEST_MAPPING फ़ाइलें इस्तेमाल करके, उससे जुड़ी डायरेक्ट्री में पहले से सबमिट किए जाने वाले टेस्ट चलाए जा सकते हैं. टेस्ट मैपिंग की मदद से, Android सोर्स ट्री में ज़्यादा बदलाव किए बिना, सबमिट करने से पहले की जाने वाली जांच में टेस्ट का वही सेट जोड़ा जा सकता है.
ये उदाहरण देखें:
services.coreके लिए,TEST_MAPPINGमें सबमिट करने से पहले किए जाने वाले टेस्ट जोड़ना
जांच की मैपिंग, जांच को लागू करने और नतीजों की रिपोर्टिंग के लिए, ट्रेड फ़ेडरेशन (टीएफ़) टेस्ट हार्नेस पर निर्भर करती है.
टेस्ट ग्रुप तय करना
टेस्ट मैपिंग ग्रुप, टेस्ट ग्रुप की मदद से टेस्ट करता है. टेस्ट ग्रुप का नाम कोई भी स्ट्रिंग हो सकती है. उदाहरण के लिए, presubmit, बदलावों की पुष्टि करते समय चलाए जाने वाले टेस्ट के ग्रुप का नाम हो सकता है. बदलावों को मर्ज करने के बाद, postsubmit टेस्ट का इस्तेमाल करके, बाइल्ड की पुष्टि की जा सकती है.
पैकेज बनाने की स्क्रिप्ट के नियम
किसी खास बिल्ड के लिए टेस्ट मॉड्यूल चलाने के लिए, Trade Federation टेस्ट हार्नेस के पास इन मॉड्यूल में से कोई एक होना चाहिए: Soong के लिए test_suites सेट या Make के लिए LOCAL_COMPATIBILITY_SUITE सेट, इन दोनों में से किसी एक सुइट में:
general-testsउन टेस्ट के लिए है जो किसी खास डिवाइस की क्षमताओं पर निर्भर नहीं होते. जैसे, वेंडर के लिए ऐसा हार्डवेयर जो ज़्यादातर डिवाइसों में उपलब्ध नहीं है. ज़्यादातर टेस्ट,general-testsसुइट में होने चाहिए. भले ही, वे किसी एक एबीआई या बिटनेस या HWASan जैसी हार्डवेयर सुविधाओं के लिए खास हों (हर एबीआई के लिए एक अलगtest_suitesटारगेट होता है). भले ही, उन्हें किसी डिवाइस पर चलाना हो.device-tests, उन टेस्ट के लिए है जो डिवाइस की खास क्षमताओं पर निर्भर करते हैं. आम तौर पर, ये टेस्टvendor/में मिलते हैं. डिवाइस के हिसाब से, सिर्फ़ उन सुविधाओं के बारे में बताया जाता है जो किसी डिवाइस के लिए खास होती हैं. इसलिए, यह JUnit टेस्ट के साथ-साथ GTest टेस्ट पर भी लागू होता है. आम तौर पर, इन टेस्ट कोgeneral-testsके तौर पर मार्क किया जाना चाहिए, भले ही वे एबीआई के हिसाब से हों.
उदाहरण:
Android.bp: test_suites: ["general-tests"],
Android.mk: LOCAL_COMPATIBILITY_SUITE := general-tests
टेस्ट सुइट में चलाने के लिए टेस्ट कॉन्फ़िगर करना
किसी टेस्ट को टेस्ट सुइट में चलाने के लिए, यह ज़रूरी है कि वह टेस्ट:
- इसमें कोई भी बिल्ड प्रोवाइडर नहीं होना चाहिए.
- टेस्ट पूरा होने के बाद, उसे साफ़ करना ज़रूरी है. उदाहरण के लिए, टेस्ट के दौरान जनरेट हुई सभी अस्थायी फ़ाइलों को मिटाना.
- सिस्टम की सेटिंग को डिफ़ॉल्ट या मूल वैल्यू पर बदलना होगा.
यह नहीं माना जाना चाहिए कि डिवाइस किसी खास स्थिति में है, जैसे कि रूट किया जा सकता है. ज़्यादातर टेस्ट चलाने के लिए, रूट प्रिविलेज की ज़रूरत नहीं होती. अगर किसी टेस्ट के लिए,
AndroidTest.xmlमेंRootTargetPreparerके साथ रूट की ज़रूरत है, तो इसकी जानकारी देनी चाहिए, जैसा कि इस उदाहरण में बताया गया है:<target_preparer class="com.android.tradefed.targetprep.RootTargetPreparer"/>
टेस्ट मैपिंग फ़ाइलें बनाएं
टेस्ट कवरेज की ज़रूरत वाली डायरेक्ट्री के लिए, उदाहरण जैसी TEST_MAPPING JSON फ़ाइल जोड़ें. इन नियमों से यह पक्का होता है कि प्री-सबमिट की मदद से जांच तब की जाए, जब उस डायरेक्ट्री या उसकी किसी भी सबडायरेक्ट्री में कोई फ़ाइल टच की गई हो.
उदाहरण देखें
यहां TEST_MAPPING फ़ाइल का एक सैंपल दिया गया है. यह JSON फ़ॉर्मैट में है, लेकिन इसमें टिप्पणियों की सुविधा काम करती है:
{
"presubmit": [
// JUnit test with options and file patterns.
{
"name": "CtsWindowManagerDeviceTestCases",
"options": [
{
"include-annotation": "android.platform.test.annotations.RequiresDevice"
}
],
"file_patterns": ["(/|^)Window[^/]*\\.java", "(/|^)Activity[^/]*\\.java"]
},
// Device-side GTest with options.
{
"name" : "hello_world_test",
"options": [
{
"native-test-flag": "\"servicename1 servicename2\""
},
{
"native-test-timeout": "6000"
}
]
}
// Host-side GTest.
{
"name" : "net_test_avrcp",
"host" : true
}
],
"postsubmit": [
{
"name": "CtsDeqpTestCases",
"options": [
{
// Use regex in include-filter which is supported in AndroidJUnitTest
"include-filter": "dEQP-EGL.functional.color_clears.*"
}
]
}
],
"imports": [
{
"path": "frameworks/base/services/core/java/com/android/server/am"
}
]
}
एट्रिब्यूट सेट करें
उदाहरण में, presubmit और postsubmit हर टेस्ट ग्रुप के नाम हैं. टेस्ट ग्रुप के बारे में ज़्यादा जानकारी के लिए, टेस्ट ग्रुप तय करना लेख पढ़ें.
name एट्रिब्यूट की वैल्यू में, टेस्ट मॉड्यूल या Trade Federation इंटिग्रेशन टेस्ट का नाम (टेस्ट एक्सएमएल फ़ाइल का रिसॉर्स पाथ, उदाहरण के लिए, uiautomator/uiautomator-demo) सेट किया जा सकता है. ध्यान दें कि name फ़ील्ड में, क्लास name या टेस्ट का तरीका name का इस्तेमाल नहीं किया जा सकता. चलाए जाने वाले टेस्ट को कम करने के लिए,include-filter जैसे विकल्पों का इस्तेमाल करें. include-filter के इस्तेमाल के उदाहरण देखें.
किसी टेस्ट की host सेटिंग से पता चलता है कि वह होस्ट पर चलने वाला डिवाइसलेस टेस्ट है या नहीं. डिफ़ॉल्ट वैल्यू false है. इसका मतलब है कि जांच को चलाने के लिए, डिवाइस की ज़रूरत होती है. GTest बाइनरी के लिए, HostGTest और JUnit टेस्ट के लिए, HostTest टाइप के टेस्ट इस्तेमाल किए जा सकते हैं.
file_patterns एट्रिब्यूट की मदद से, रेगुलर एक्सप्रेशन स्ट्रिंग की सूची सेट की जा सकती है. इससे किसी भी सोर्स कोड फ़ाइल के रिलेटिव पाथ (TEST_MAPPING फ़ाइल वाली डायरेक्ट्री के हिसाब से) से मैच किया जा सकता है. उदाहरण में, जांच CtsWindowManagerDeviceTestCases सिर्फ़ तब सबमिट करने से पहले चलती है, जब कोई Java फ़ाइल Window या Activity से शुरू होती है. यह फ़ाइल, TEST_MAPPING फ़ाइल या उसकी किसी सबडायरेक्ट्री में मौजूद होनी चाहिए. बैकस्लैश (\) को एस्केप करना ज़रूरी है, क्योंकि ये JSON फ़ाइल में होते हैं.
imports एट्रिब्यूट की मदद से, कॉन्टेंट को कॉपी किए बिना, अन्य TEST_MAPPING फ़ाइलों में टेस्ट शामिल किए जा सकते हैं. इंपोर्ट किए गए पाथ की पैरंट डायरेक्ट्री में मौजूद TEST_MAPPING फ़ाइलें भी शामिल की जाती हैं. टेस्ट मैपिंग की मदद से, नेस्ट किए गए इंपोर्ट किए जा सकते हैं. इसका मतलब है कि दो TEST_MAPPING फ़ाइलें एक-दूसरे को इंपोर्ट कर सकती हैं और टेस्ट मैपिंग, शामिल किए गए टेस्ट को मर्ज कर सकती है.
options एट्रिब्यूट में, ट्रेडेड कमांड लाइन के अन्य विकल्प मौजूद हैं.
किसी दिए गए टेस्ट के लिए उपलब्ध विकल्पों की पूरी सूची पाने के लिए, इसे चलाएं:
tradefed.sh run commandAndExit [test_module] --help
विकल्पों के काम करने के तरीके के बारे में ज़्यादा जानने के लिए, Tradefed में विकल्प मैनेज करने का तरीका लेख पढ़ें.
Atest की मदद से टेस्ट चलाना
सबमिट करने से पहले की जाने वाली जांच के नियमों को स्थानीय तौर पर लागू करने के लिए:
TEST_MAPPINGफ़ाइल वाली डायरेक्ट्री पर जाएं.यह कमांड चलाएं:
atest
मौजूदा डायरेक्ट्री और उसकी पैरंट डायरेक्ट्री की TEST_MAPPING फ़ाइलों में कॉन्फ़िगर किए गए, सबमिट करने से पहले किए जाने वाले सभी टेस्ट चलाए जाते हैं. Atest, सबमिट करने से पहले (A और B) दो टेस्ट ढूंढता है और उन्हें चलाता है.
मौजूदा वर्किंग डायरेक्ट्री (CWD) और पैरंट डायरेक्ट्री में मौजूद TEST_MAPPING
फ़ाइलों में, सबमिट करने से पहले टेस्ट चलाने का यह सबसे आसान तरीका है. Atest, CWD और उसकी सभी पैरंट डायरेक्ट्री में TEST_MAPPING फ़ाइल को ढूंढता है और उसका इस्तेमाल करता है.
स्ट्रक्चर का सोर्स कोड
इस उदाहरण में बताया गया है कि सोर्स ट्री में TEST_MAPPING फ़ाइलों को कैसे कॉन्फ़िगर किया जा सकता है:
src
├── project_1
│ └── TEST_MAPPING
├── project_2
│ └── TEST_MAPPING
└── TEST_MAPPING
src/TEST_MAPPING का कॉन्टेंट:
{
"presubmit": [
{
"name": "A"
}
]
}
src/project_1/TEST_MAPPING का कॉन्टेंट:
{
"presubmit": [
{
"name": "B"
}
],
"postsubmit": [
{
"name": "C"
}
],
"other_group": [
{
"name": "X"
}
]}
src/project_2/TEST_MAPPING का कॉन्टेंट:
{
"presubmit": [
{
"name": "D"
}
],
"import": [
{
"path": "src/project_1"
}
]}
टारगेट डायरेक्ट्री की जानकारी दें
किसी डायरेक्ट्री में मौजूद TEST_MAPPING फ़ाइलों में टेस्ट चलाने के लिए, उस डायरेक्ट्री को टारगेट के तौर पर चुना जा सकता है. यह निर्देश दो टेस्ट (A, B) चलाता है:
atest --test-mapping src/project_1
सबमिट करने के बाद चलने वाले टेस्ट के नियम चलाना
इस निर्देश का इस्तेमाल, src_path (डिफ़ॉल्ट तौर पर CWD) और इसकी पैरंट डायरेक्ट्री के साथ-साथ, src_path में TEST_MAPPING में बताए गए पोस्टसबमिट की जांच के नियमों को चलाने के लिए भी किया जा सकता है:
atest [--test-mapping] [src_path]:postsubmit
सिर्फ़ ऐसे टेस्ट चलाएं जिनके लिए किसी डिवाइस की ज़रूरत न हो
Atest के लिए --host विकल्प का इस्तेमाल करके, सिर्फ़ उन टेस्ट को चलाया जा सकता है जिन्हें होस्ट के लिए कॉन्फ़िगर किया गया है और जिनके लिए किसी डिवाइस की ज़रूरत नहीं होती. इस विकल्प के बिना, Atest दोनों तरह के टेस्ट चलाता है. पहला, वह टेस्ट जिसमें डिवाइस की ज़रूरत होती है और दूसरा, वह टेस्ट जो होस्ट पर चलता है और जिसमें डिवाइस की ज़रूरत नहीं होती. ये टेस्ट दो अलग-अलग सुइट में चलाए जाते हैं:
atest [--test-mapping] --host
टेस्ट ग्रुप की पहचान करना
Atest कमांड में टेस्ट ग्रुप तय किए जा सकते हैं. यह कमांड, src/project_1 डायरेक्ट्री में मौजूद फ़ाइलों से जुड़े सभी postsubmit टेस्ट चलाता है. इसमें सिर्फ़ एक टेस्ट (C) शामिल है.
इसके अलावा, ग्रुप के हिसाब से सभी टेस्ट चलाने के लिए, :all का इस्तेमाल किया जा सकता है. यह कमांड चार टेस्ट (A, B, C, X) चलाता है:
atest --test-mapping src/project_1:all
सब-डायरेक्ट्री शामिल करना
डिफ़ॉल्ट रूप से, Atest के साथ TEST_MAPPING में टेस्ट चलाने पर, सिर्फ़ CWD (या दी गई डायरेक्ट्री) और उसकी पैरंट डायरेक्ट्री में मौजूद TEST_MAPPING फ़ाइल में कॉन्फ़िगर किए गए, सबमिट करने से पहले किए जाने वाले टेस्ट चलते हैं. अगर आपको सब-डायरेक्ट्री में मौजूद सभी TEST_MAPPING फ़ाइलों में टेस्ट चलाने हैं, तो --include-subdir विकल्प का इस्तेमाल करके, Atest को उन टेस्ट को भी शामिल करने के लिए मजबूर करें.
atest --include-subdir
--include-subdir विकल्प के बिना, Atest सिर्फ़ टेस्ट A चलाता है. --include-subdir विकल्प की मदद से, Atest दो टेस्ट (A, B) चलाता है.
लाइन-लेवल पर टिप्पणी करने की सुविधा काम करती है
TEST_MAPPING फ़ाइल में मौजूद सेटिंग के बारे में जानकारी देने के लिए, लाइन-लेवल // फ़ॉर्मैट की टिप्पणी जोड़ी जा सकती है.
ATest और ट्रेड फ़ेडरेशन, TEST_MAPPING को बिना टिप्पणियों के एक मान्य JSON फ़ॉर्मैट में प्रीप्रोसेस करता है. JSON फ़ाइल को साफ़ रखने के लिए, सिर्फ़ लाइन लेवल पर मौजूद // फ़ॉर्मैट की टिप्पणी ही इस्तेमाल की जा सकती है.
उदाहरण:
{
// For presubmit test group.
"presubmit": [
{
// Run test on module A.
"name": "A"
}
]
}