यह टेस्ट मैपिंग के बारे में कम शब्दों में जानकारी देता है. साथ ही, इसमें यह भी बताया गया है कि कैसे ने Android ओपन सोर्स प्रोजेक्ट (AOSP) में टेस्ट कॉन्फ़िगर करना शुरू कर दिया है.
टेस्ट मैपिंग के बारे में जानकारी
टेस्ट मैपिंग, गेरिट पर आधारित अप्रोच है. इसकी मदद से डेवलपर,
और टेस्ट नियमों को सबमिट करने के बाद, उन्हें सीधे Android सोर्स ट्री में जोड़ दिया जाता है.
उन ब्रांच और डिवाइसों के फ़ैसलों को भी टेस्ट किया जा सकता है जिनकी जांच बुनियादी ढांचे के लिए की जानी है.
टेस्ट मैपिंग की परिभाषाएं, TEST_MAPPING नाम की JSON फ़ाइलें होती हैं. इन्हें आपके पास किया जा सकता है
किसी भी सोर्स डायरेक्ट्री में डाला जा सकता है.
Atest में TEST_MAPPING फ़ाइलों का इस्तेमाल करके,
जुड़ी हुई डायरेक्ट्री. टेस्ट मैपिंग की मदद से, आपके पास टेस्ट का एक जैसा सेट,
Android सोर्स ट्री में कम से कम बदलाव करके, पहले से सबमिट की जाने वाली जांच की जा सकती है.
ये उदाहरण देखें:
इसके लिए
TEST_MAPPINGमें प्री-सबमिट टेस्ट जोड़ेंservices.coreइसका इस्तेमाल करके
tools/dexterके लिए,TEST_MAPPINGमें प्री-सबमिट टेस्ट जोड़ें इंपोर्ट
टेस्ट मैपिंग इन बातों पर निर्भर करती है: ट्रेड फ़ेडरेशन (टीएफ़) का टेस्ट हार्नेस एक्ज़ीक्यूशन और नतीजों की रिपोर्टिंग.
टेस्ट ग्रुप तय करें
टेस्ट ग्रुप की मदद से, मैपिंग ग्रुप की जांच को टेस्ट करें. टेस्ट ग्रुप का नाम यह हो सकता है: कोई भी स्ट्रिंग. उदाहरण के लिए, पहले से सबमिट करना, टेस्ट के ग्रुप का नाम हो सकता है चलाएं. इसके अलावा, पोस्टसबमिट करें ऐसी जांच हो सकती है जिसका इस्तेमाल बदलावों के बाद बिल्ड मर्ज कर दिए जाते हैं.
पैकेज बिल्ड स्क्रिप्ट के नियम
ट्रेड फ़ेडरेशन टेस्ट हार्नेस के लिए
किसी दिए गए बिल्ड के टेस्ट मॉड्यूल चलाने के लिए, इन मॉड्यूल में
Soong या LOCAL_COMPATIBILITY_SUITE सेट के लिए test_suites सेट
इन दो सुइट में से एक के लिए:
general-testsउन टेस्ट के लिए है जो किसी खास डिवाइस पर निर्भर नहीं करते सुविधाएं (जैसे कि वेंडर के लिए खास हार्डवेयर, जो ज़्यादातर डिवाइस के लिए उपलब्ध नहीं है) . ज़्यादातर जांचgeneral-testsसुइट में होनी चाहिए, भले ही वे एक ABI या बिटनेस या हार्डवेयर सुविधाओं के लिए विशिष्ट हो, जैसे 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": "CtsWindowManagerDeviceTestCases"
}
],
"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 है. इसका मतलब है कि टेस्ट
इसे चलाने के लिए डिवाइस ज़रूरी है. इन टेस्ट टाइप का इस्तेमाल किया जा सकता है
इसके लिए HostGTest:
JUnit के लिए GTest बाइनरी और 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
इससे संदर्भ लें Trafed में विकल्प को मैनेज करना देखें.
Atest की मदद से टेस्ट चलाना
टेस्ट से जुड़े नियमों को पहले से ही स्थानीय तौर पर लागू करने के लिए:
- उस डायरेक्ट्री पर जाएं जिसमें
TEST_MAPPINGफ़ाइल है. निर्देश चलाएं:
atest
मौजूदा फ़ाइल की TEST_MAPPING फ़ाइलों में, पहले से सबमिट किए गए सभी टेस्ट कॉन्फ़िगर कर दिए गए हैं
डायरेक्ट्री और इसकी पैरंट डायरेक्ट्री चलती हैं. Aटेस्ट दो टेस्ट का पता लगाता है और चलाता है
सबमिट करें (A और B).
यह, TEST_MAPPING में प्री-सबमिट टेस्ट चलाने का सबसे आसान तरीका है
फ़ाइलें, मौजूदा वर्किंग डायरेक्ट्री (CWD) और पैरंट डायरेक्ट्री में मौजूद हैं. एटेस्ट
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 और ट्रेड फ़ेडरेशन
TEST_MAPPING को बिना टिप्पणियों वाले मान्य JSON फ़ॉर्मैट में प्रीप्रोसेस करें. सेव रखने के लिए
JSON फ़ाइल को हटाया गया, सिर्फ़ लाइन-लेवल की // फ़ॉर्मैट वाली टिप्पणी
समर्थित है.
उदाहरण:
{
// For presubmit test group.
"presubmit": [
{
// Run test on module A.
"name": "A"
}
]
}