इस लेख में, टेस्ट मैपिंग के बारे में कम शब्दों में जानकारी दी गई है. साथ ही, Android Open Source Project (AOSP) में टेस्ट कॉन्फ़िगर करने का तरीका भी बताया गया है.
टेस्ट मैपिंग के बारे में जानकारी
टेस्ट मैपिंग, 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 कमांड लाइन के अन्य विकल्प शामिल होते हैं.
किसी टेस्ट के लिए उपलब्ध विकल्पों की पूरी सूची पाने के लिए, यह चलाएं:
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) और उसकी पैरंट डायरेक्ट्री में, 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 और Trade Federation, TEST_MAPPING को बिना टिप्पणियों के मान्य JSON फ़ॉर्मैट में प्रीप्रोसेस करते हैं. JSON फ़ाइल को साफ़ रखने के लिए, सिर्फ़ लाइन-लेवल // फ़ॉर्मैट की टिप्पणी का इस्तेमाल किया जा सकता है.
उदाहरण:
{
// For presubmit test group.
"presubmit": [
{
// Run test on module A.
"name": "A"
}
]
}