इस लेख में, टेस्ट मैपिंग के बारे में कम शब्दों में जानकारी दी गई है. साथ ही, Android Open Source Project (AOSP) में टेस्ट कॉन्फ़िगर करने का तरीका भी बताया गया है.
टेस्ट मैपिंग के बारे में जानकारी
टेस्ट मैपिंग, गेरिट पर आधारित अप्रोच है. इसकी मदद से डेवलपर, पहले से सबमिट फ़ॉर्म बना सकते हैं
और टेस्ट के नियमों को सीधे Android सोर्स ट्री में सबमिट करने के बाद,
उन ब्रांच और डिवाइसों के फ़ैसलों को भी टेस्ट किया जा सकता है जिनकी जांच बुनियादी ढांचे के लिए की जानी है.
टेस्ट मैपिंग की परिभाषाएं, TEST_MAPPING नाम की JSON फ़ाइलें होती हैं. इन्हें किसी भी सोर्स डायरेक्ट्री में रखा जा सकता है.
Atest, TEST_MAPPING फ़ाइलों का इस्तेमाल करके, इससे जुड़ी डायरेक्ट्री में सबमिट करने से पहले की जाने वाली जांच चला सकता है. टेस्ट मैपिंग की मदद से, आपके पास टेस्ट का एक जैसा सेट,
Android सोर्स ट्री में कम से कम बदलाव करके, पहले से सबमिट की जाने वाली जांच की जा सकती है.
ये उदाहरण देखें:
जांच की मैपिंग, जांच को लागू करने और नतीजों की रिपोर्टिंग के लिए, ट्रेड फ़ेडरेशन (टीएफ़) टेस्ट हार्नेस पर निर्भर करती है.
टेस्ट ग्रुप तय करना
टेस्ट मैपिंग ग्रुप, टेस्ट ग्रुप की मदद से टेस्ट करता है. टेस्ट ग्रुप का नाम यह हो सकता है: कोई भी स्ट्रिंग. उदाहरण के लिए, presubmit, बदलावों की पुष्टि करते समय चलाए जाने वाले टेस्ट के ग्रुप का नाम हो सकता है. बदलावों को मर्ज करने के बाद, postsubmit टेस्ट का इस्तेमाल करके, बाइल्ड की पुष्टि की जा सकती है.
पैकेज बिल्ड स्क्रिप्ट के नियम
ट्रेड फ़ेडरेशन टेस्ट हार्नेस के लिए
किसी दिए गए बिल्ड के टेस्ट मॉड्यूल चलाने के लिए, इन मॉड्यूल में
Soong या LOCAL_COMPATIBILITY_SUITE सेट के लिए test_suites सेट
इन दो सुइट में से एक के लिए:
general-testsउन जांचों के लिए है जो डिवाइस के हिसाब से उपलब्ध सुविधाओं पर निर्भर नहीं होती हैं. जैसे, वेंडर के हिसाब से उपलब्ध हार्डवेयर, जो ज़्यादातर डिवाइसों में नहीं होता. ज़्यादातर टेस्ट,general-testsसुइट में होने चाहिए. भले ही, वे किसी एक एबीआई या बिटनेस या HWASan जैसी हार्डवेयर सुविधाओं के लिए खास हों (हर एबीआई के लिए एक अलगtest_suitesटारगेट होता है). भले ही, उन्हें किसी डिवाइस पर चलाना हो.device-tests, उन टेस्ट के लिए है जो डिवाइस की खास सुविधाओं पर निर्भर करते हैं. आम तौर पर, ये टेस्टvendor/में मिलते हैं. डिवाइस के हिसाब से सिर्फ़ उन क्षमताओं के बारे में बताता है जो a डिवाइस की खास होती हैं. इसलिए, यह लागू होता है को JUnit परीक्षणों और GTest परीक्षणों के रूप में (जिन्हें आम तौर परgeneral-tests, भले ही वे एबीआई के हिसाब से हों).
उदाहरण:
Android.bp: test_suites: ["general-tests"],
Android.mk: LOCAL_COMPATIBILITY_SUITE := general-tests
टेस्ट सुइट में चलाने के लिए टेस्ट कॉन्फ़िगर करना
किसी टेस्ट को टेस्ट सुइट में चलाने के लिए, यह ज़रूरी है कि वह टेस्ट:
- इसमें कोई भी बिल्ड प्रोवाइडर नहीं होना चाहिए.
- टेस्ट पूरा होने के बाद, उसे साफ़ करना ज़रूरी है. उदाहरण के लिए, टेस्ट के दौरान जनरेट हुई सभी अस्थायी फ़ाइलों को मिटाना.
- सिस्टम की सेटिंग को डिफ़ॉल्ट या ओरिजनल वैल्यू में बदलना होगा.
यह नहीं माना जाना चाहिए कि डिवाइस किसी खास स्थिति में है, जैसे कि रूट किया जा सकता है. ज़्यादातर टेस्ट चलाने के लिए, रूट प्रिविलेज की ज़रूरत नहीं होती. टेस्ट के लिए ज़रूरी रूट है, तो इसे यह बताया जाना चाहिए कि
RootTargetPreparerके साथAndroidTest.xml, जैसा कि नीचे दिए गए उदाहरण में बताया गया है:<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 दोनों के नाम हैं
टेस्ट ग्रुप. टेस्ट ग्रुप के बारे में ज़्यादा जानकारी के लिए, टेस्ट ग्रुप तय करना लेख पढ़ें.
आपके पास टेस्ट मॉड्यूल या ट्रेड फ़ेडरेशन इंटिग्रेशन टेस्ट का नाम सेट करने का विकल्प होता है
नाम (टेस्ट एक्सएमएल फ़ाइल के लिए संसाधन पाथ, उदाहरण के लिए,
uiautomator/uiautomator-demo)
को name एट्रिब्यूट की वैल्यू में डालें. ध्यान दें कि 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 फ़ाइलों में, पहले से सबमिट किए गए सभी टेस्ट कॉन्फ़िगर कर दिए गए हैं
डायरेक्ट्री और इसकी पैरंट डायरेक्ट्री चलती हैं. Aटेस्ट दो टेस्ट का पता लगाता है और चलाता है
सबमिट करें (A और B).
मौजूदा वर्किंग डायरेक्ट्री (CWD) और पैरंट डायरेक्ट्री में मौजूद TEST_MAPPING
फ़ाइलों में, सबमिट करने से पहले टेस्ट चलाने का यह सबसे आसान तरीका है. एटेस्ट
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 में TEST_MAPPING (CWD पर डिफ़ॉल्ट रूप से सेट होती है) और इसकी पैरंट डायरेक्ट्री:
atest [--test-mapping] [src_path]:postsubmit
सिर्फ़ ऐसे टेस्ट चलाएं जिनके लिए किसी डिवाइस की ज़रूरत न हो
सिर्फ़ कॉन्फ़िगर की गई जांचों को चलाने के लिए, टेस्ट के लिए --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"
}
]
}