यह टेस्ट मैपिंग के बारे में कम शब्दों में बताया गया है. साथ ही, इसमें यह भी बताया गया है कि Android ओपन सोर्स प्रोजेक्ट (एओएसपी) में, टेस्ट को आसानी से कॉन्फ़िगर करने का तरीका क्या है.
टेस्ट मैपिंग के बारे में जानकारी
टेस्ट मैपिंग, गेरिट पर आधारित एक तरीका है. इसकी मदद से डेवलपर, सीधे Android सोर्स ट्री में टेस्ट से जुड़े नियम बना सकते हैं. इसके बाद, वे ब्रांच और डिवाइसों से जुड़े फ़ैसले खुद ही टेस्ट इन्फ़्रास्ट्रक्चर पर टेस्ट करने के लिए छोड़ सकते हैं. टेस्ट मैपिंग की परिभाषाएं, TEST_MAPPING नाम की JSON फ़ाइलें होती हैं. इन्हें किसी भी सोर्स डायरेक्ट्री में रखा जा सकता है.
Atest इससे जुड़ी डायरेक्ट्री में प्री-सबमिट टेस्ट चलाने के लिए, TEST_MAPPING फ़ाइलों का इस्तेमाल कर सकता है. टेस्ट मैपिंग की मदद से, Android सोर्स ट्री में एक आसान बदलाव करके, पहले से जांच सबमिट करने के लिए, टेस्ट का एक ही सेट जोड़ा जा सकता है.
ये उदाहरण देखें:
services.core के लिए TEST_MAPPING में प्री-सबमिट टेस्ट जोड़ना
इंपोर्ट का इस्तेमाल करके टूल/डेक्स्टर के लिए, TEST_MAPPING में प्री-सबमिट टेस्ट जोड़ना
टेस्ट की मैपिंग और परफ़ॉर्मेंस की जांच के लिए, ट्रेड फ़ेडरेशन (टीएफ़) टेस्ट हार्नेस का इस्तेमाल किया जाता है.
टेस्ट ग्रुप तय करें
टेस्ट ग्रुप के ज़रिए मैपिंग ग्रुप टेस्ट टेस्ट करें. टेस्ट ग्रुप का नाम, कोई भी स्ट्रिंग हो सकता है. उदाहरण के लिए, पहले से सबमिट करना, बदलावों की पुष्टि करते समय चलाए जाने वाले टेस्ट के ग्रुप के लिए हो सकता है. इसके अलावा, बदलावों को मर्ज करने के बाद, बिल्ड की पुष्टि करने के लिए पोस्टसबमिट टेस्ट का इस्तेमाल किया जा सकता है.
पैकेज बिल्ड स्क्रिप्ट के नियम
किसी दिए गए बिल्ड के लिए टेस्ट मैपिंग के टेस्ट मॉड्यूल चलाने के लिए, Trade समूह Test Harness की मदद से, इन मॉड्यूल में Soong के लिए test_suites सेट होने चाहिए या इन दोनों में से किसी एक सुइट के लिए LOCAL_COMPATIBILITY_SUITE सेट होना चाहिए:
- सामान्य जांच - ऐसी जांच जो डिवाइस से जुड़ी खास सुविधाओं पर निर्भर नहीं करती हैं (जैसे कि वेंडर के लिए ऐसा हार्डवेयर जो ज़्यादातर डिवाइसों में मौजूद नहीं है). ज़्यादातर टेस्ट, सामान्य टेस्ट सुइट में होने चाहिए. ऐसा तब भी होना चाहिए, जब वे खास तौर पर किसी एक एबीआई या बिटनेस या हार्डवेयर सुविधाओं के लिए ही हों, जैसे कि HWASan (हर एबीआई के लिए अलग-अलग test_suites टारगेट दिए गए हैं) और फिर चाहे उन्हें डिवाइस पर चलाना क्यों न हो.
- डिवाइस-टेस्ट - ऐसे टेस्ट जो डिवाइस के फ़ंक्शन पर निर्भर करते हैं.
आम तौर पर, ये जांच
vendor/में दिखेंगी. "खास तौर पर डिवाइस" में एबीआई या एसओसी की सुविधाएं नहीं मिलतीं, जो शायद अन्य डिवाइसों में हों या न हों. हालांकि, यह सिर्फ़ a डिवाइस की यूनीक सुविधाओं के लिए है. यह GUnit टेस्ट की तरह, 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": "CtsWindowManagerDeviceTestCases"
}
],
"imports": [
{
"path": "frameworks/base/services/core/java/com/android/server/am"
}
]
}
एट्रिब्यूट सेट करें
ऊपर दिए गए उदाहरण में, presubmit और postsubmit हर टेस्ट ग्रुप के नाम हैं. टेस्ट ग्रुप के बारे में ज़्यादा जानकारी के लिए, टेस्ट ग्रुप तय करना देखें.
टेस्ट मॉड्यूल या Trade फ़ेडरेशन टेस्ट का नाम (टेस्ट एक्सएमएल फ़ाइल के लिए संसाधन पाथ, जैसे कि uiautomator/uiautomator-demo) का नाम, name एट्रिब्यूट की वैल्यू में सेट किया जा सकता है. ध्यान दें कि name फ़ील्ड में क्लास name या टेस्ट तरीके name का इस्तेमाल नहीं किया जा सकता. जांच को सटीक बनाने के लिए, यहां include-filter जैसे विकल्प इस्तेमाल किए जा सकते हैं. देखें
(शामिल करने के लिए फ़िल्टर का सैंपल इस्तेमाल).
टेस्ट की होस्ट सेटिंग से पता चलता है कि टेस्ट, बिना डिवाइस के होस्ट पर चल रहा टेस्ट है या नहीं. डिफ़ॉल्ट वैल्यू false है, इसका मतलब है कि टेस्ट चलाने के लिए डिवाइस की ज़रूरत होती है. काम करने वाले टेस्ट टाइप, GTest बाइनरी के लिए HostGTest और JUnit टेस्ट के लिए HostTest हैं.
file_patterns एट्रिब्यूट की मदद से, रेगुलर एक्सप्रेशन स्ट्रिंग की एक सूची सेट की जा सकती है. इससे, किसी भी सोर्स कोड फ़ाइल के रिलेटिव पाथ से मैच किया जा सकता है. यह डायरेक्ट्री, TEST_MAPPING फ़ाइल वाली डायरेक्ट्री के डेटा से मेल खाती है. ऊपर दिए गए उदाहरण में, टेस्ट CtsWindowManagerDeviceTestCases
पहले से सबमिट किए गए कोड में सिर्फ़ तब चलेगा, जब किसी JavaScript फ़ाइल की शुरुआत विंडो या ऐक्टिविटी से
होती है, जो TEST_MAPPING फ़ाइल या इसकी किसी भी सबडायरेक्ट्री की उसी डायरेक्ट्री में मौजूद होती है. JSON फ़ाइल में, बैकस्लैश \ को एस्केप करना ज़रूरी है.
इंपोर्ट एट्रिब्यूट की मदद से, कॉन्टेंट को कॉपी किए बिना, अन्य TEST_MAPPING फ़ाइलों में टेस्ट शामिल किए जा सकते हैं. ध्यान दें कि इंपोर्ट किए गए पाथ की पैरंट डायरेक्ट्री में मौजूद TEST_MAPPING फ़ाइलों को भी शामिल किया जाएगा. टेस्ट मैपिंग, नेस्ट किए गए इंपोर्ट की अनुमति देती है. इसका मतलब है कि दो TEST_MAPPING फ़ाइलें एक-दूसरे से इंपोर्ट हो सकती हैं. साथ ही, टेस्ट मैपिंग, शामिल किए गए टेस्ट को सही तरीके से मर्ज कर सकती है.
options एट्रिब्यूट में, TreFed के अतिरिक्त कमांड लाइन के विकल्प मौजूद होते हैं.
किसी दिए गए टेस्ट के लिए उपलब्ध विकल्पों की पूरी सूची पाने के लिए, इसे चलाएं:
tradefed.sh run commandAndExit [test_module] --help
विकल्पों के काम करने के तरीके के बारे में ज़्यादा जानने के लिए, ट्रेडएफ़ेड विकल्प की हैंडलिंग लेख पढ़ें.
Atest की मदद से टेस्ट चलाना
टेस्ट से जुड़े नियमों को पहले से ही स्थानीय तौर पर लागू करने के लिए:
- TEST_MAPPING फ़ाइल वाली डायरेक्ट्री पर जाएं.
- निर्देश चलाएं:
atest
मौजूदा डायरेक्ट्री और इसकी पैरंट डायरेक्ट्री की TEST_MAPPING फ़ाइलों में कॉन्फ़िगर किए गए सभी प्री-सबमिट टेस्ट चलाए जाते हैं. Aटेस्ट, पहले से सबमिट करने के लिए दो टेस्ट का पता लगाएगा और उन्हें चलाएगा (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 पर डिफ़ॉल्ट तौर पर CWD) में तय किए गए, पोस्टसबमिट टेस्ट के नियमों और इसकी पैरंट डायरेक्ट्री को चलाने के लिए भी किया जा सकता है:
atest [--test-mapping] [src_path]:postsubmit
सिर्फ़ ऐसी जांच करें जिनके लिए किसी डिवाइस की ज़रूरत न हो
आप Atest के लिए --होस्ट विकल्प का इस्तेमाल सिर्फ़ उस होस्ट के लिए कॉन्फ़िगर किए गए टेस्ट चलाने के लिए कर सकते हैं जिसके लिए किसी डिवाइस की ज़रूरत नहीं होती. इस विकल्प के बिना, 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 फ़ाइलों में टेस्ट चलाना है, तो Atest में भी उन टेस्ट को भी शामिल करने के लिए --include-subdir विकल्प का इस्तेमाल करें.
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"
}
]
}