इस पेज पर ACTS टेस्ट कॉन्फ़िगर करने का तरीका बताया गया है.
कॉन्फ़िगरेशन के सोर्स
Android Comms Test Suite (ACTS) में कॉन्फ़िगरेशन के तीन मुख्य सोर्स होते हैं:
- कमांड-लाइन इंटरफ़ेस (सीएलआई)
- ACTS कॉन्फ़िगरेशन फ़ाइल
- एनवायरमेंट वैरिएबल
इन सोर्स की वैल्यू को एक कॉन्फ़िगरेशन में जोड़ दिया जाता है. इसका इस्तेमाल, ACTS टेस्ट चलाने के लिए किया जाता है. अगर वैल्यू एक से ज़्यादा जगहों पर दी गई हैं, तो ऊपर दिए गए क्रम के आधार पर वैल्यू को बदल दिया जाता है. इसमें सीएलआई को प्राथमिकता दी जाती है.
एनवायरमेंट वैरिएबल के बारे में जानकारी
ACTS टेस्ट के लिए, एनवायरमेंट वैरिएबल का इस्तेमाल करते समय सावधानी बरतें. ये वैल्यू, उपयोगकर्ता को कम ही दिखती हैं. साथ ही, हमारा सुझाव है कि इन्हें डेवलपर के वर्कस्टेशन के बाहर इस्तेमाल न करें. एनवायरमेंट को नुकसान पहुंचाने से बचाने के लिए, ACTS के अपने-आप होने वाले टेस्ट के दौरान एनवायरमेंट वैरिएबल बंद कर दिए जाते हैं.
ज़रूरी कॉन्फ़िगरेशन वैरिएबल
हर ACTS टेस्ट में नीचे दिए गए वैरिएबल सेट होने चाहिए.
ACTS टेस्ट पाथ
ACTS, एक ही मुख्य एंट्री लोकेशन से चलता है. इस वजह से, रनर को टेस्ट पाथ की जगह की जानकारी नहीं होती.
ACTS_TESTPATH एनवायरमेंट वैरिएबल का इस्तेमाल करके या कमांड लाइन में -tp/--testpaths फ़्लैग की मदद से, टेस्ट पाथ की जगह सेट करें. वैल्यू, डायरेक्ट्री की सूची हो सकती है.
ACTS की टेस्ट क्लास
ACTS को यह पता होना चाहिए कि कौनसी टेस्ट क्लास चलानी हैं. यह रेगुलर एक्सप्रेशन या टेस्ट क्लास के नामों की सूची हो सकती है.
इस वैल्यू को सेट करने के लिए, कमांड लाइन में -tc/--test_class फ़्लैग का इस्तेमाल करें. ध्यान दें कि इस फ़्लैग में क्लास के नामों की सूची भी डाली जा सकती है. क्लास के नाम, उनसे जुड़ी फ़ाइल के नाम से मेल खाने चाहिए. उदाहरण के लिए, SampleTest को SampleTest.py में ढूंढा जाना चाहिए.
ACTS लॉग का पाथ
ACTS में, STDOUT के अलावा लॉग लिखने के लिए कोई जगह होनी चाहिए. ACTS, पूरी तरह से डीबग करने वाले लॉग लिखता है. इनमें ऐसा डेटा होता है जिससे यह पता लगाया जा सकता है कि कुछ टेस्ट क्यों काम नहीं कर रहे हैं. फ़ाइलों को व्यवस्थित करने के लिए, ACTS इन लॉग को STDOUT पर नहीं लिखता.
लॉग पाथ सेट करने के लिए, कमांड लाइन में ACTS_LOGPATH एनवायरमेंट वैरिएबल या -lp/--logpath फ़्लैग का इस्तेमाल करें.
ACTS कॉन्फ़िगरेशन पाथ
जांच करने के लिए, ACTS को यह पता होना चाहिए कि कौनसा टेस्टबेड मौजूद है. ACTS कॉन्फ़िगरेशन में टेस्ट किए गए सभी डिवाइस शामिल होते हैं. साथ ही, टेस्ट या एनवायरमेंट के ऐसे खास पैरामीटर भी शामिल होते हैं जिनकी ज़रूरत पड़ सकती है. -c/--config का इस्तेमाल करके, कमांड लाइन पर यह वैल्यू सेट करें.
अगर कॉन्फ़िगरेशन में एक से ज़्यादा टेस्टबेड हैं, तो ACTS टेस्ट किए गए हर टेस्टबेड के लिए
जांच करता है. सूची में मौजूद किसी एक टेस्टबेड के लिए ही टेस्ट चलाने के लिए, -tb/--testbed <NAME> कमांड लाइन आर्ग्युमेंट का इस्तेमाल करें.
स्थानीय वर्कस्टेशन का उदाहरण
ACTS के ज़्यादातर उपयोगकर्ता एक ही Android रेपो ब्रांच पर डेवलप करते हैं और उनका सेटअप इससे मिलता-जुलता है:
# in ~/.bashrc
ACTS_LOGPATH='/tmp/acts_logpath'
ACTS_TESTPATH='~/android/<REPO_BRANCH>/tools/test/connectivity/acts_tests/'
# On cmdline
$ act.py -c ~/acts_configs/local_config.json -tc SampleTest -tb marlin
अगर ACTS के उपयोगकर्ता एक से ज़्यादा शाखाओं पर काम करते हैं, तो वे अक्सर acts/framework डायरेक्ट्री से ACTS चलाते हैं और ACTS_TESTPATH के लिए रिलेटिव पाथ का इस्तेमाल करते हैं:
# in ~/.bashrc
ACTS_LOGPATH='/tmp/acts_logpath'
ACTS_TESTPATH='../acts_tests/'
# On cmdline
$ cd ~/android/main/tools/test/connectivity/acts_tests/acts_contrib/
$ act.py -c ~/acts_configs/local_config.json -tc SampleTest -tb marlin
अपने टेस्टबेड कॉन्फ़िगर करें
ACTS कॉन्फ़िगरेशन फ़ाइल, हार्डवेयर डिवाइसों पर जांच करने के लिए ज़रूरी जानकारी देती है:
{
"testbed": {
"my_testbed": {
"my_testbed_value": "value"
},
"another_testbed": {
"AndroidDevice": [
"53R147"
]
}
},
"user_parameter_1": "special environment value",
"user_parameter_2": "other special value"
}
इस कॉन्फ़िगरेशन की बेस यूनिट, टेस्टबेड है. ऊपर दिए गए उदाहरण के कॉन्फ़िगरेशन में, टेस्टबेड my_testbed को एक टेस्टबेड वैल्यू के साथ बनाया गया है. दूसरे टेस्टबेड, another_testbed में एक खास कंट्रोलर कॉन्फ़िगरेशन है, जिसमें Android डिवाइसों की सूची की जानकारी होती है. इन डिवाइसों को self.android_devices से जुड़े डिवाइसों की सूची में सेव किया गया है. ध्यान दें कि अगर किसी testbed में AndroidDevice ऑब्जेक्ट की जानकारी नहीं दी गई है, तो AndroidDevice ऑब्जेक्ट की उम्मीद करने वाली टेस्ट क्लास को अपवाद माना जाएगा. ACTS के साथ काम करने वाले कंट्रोलर कॉन्फ़िगरेशन की पूरी सूची देखने के लिए, /acts/framework/acts/controllers/ पर जाएं.
ऊपर दिए गए सेक्शन में बताई गई खास वैल्यू के अलावा, सभी अन्य वैल्यू को self.user_params में डिक्शनरी के तौर पर सेव किया जाता है. यह एनवायरमेंट या टेस्ट से जुड़ी जानकारी रखने के लिए अच्छी जगह है, जैसे कि फ़ोन सीमित डेटा वाले एनवायरमेंट में हैं या टेस्ट के लिए डेटा को कितनी देर तक इकट्ठा करना है.
AndroidDevice के लिए खास मामले
अगर आपको अलग-अलग प्रॉपर्टी वाले एक से ज़्यादा डिवाइसों पर ऐप्लिकेशन डेवलप करना है, तो AndroidDevice में कुछ खास उदाहरण दिए गए हैं.
JSON कॉन्फ़िगरेशन फ़ॉर्मैट
यहां दिए गए JSON उदाहरण में, सभी की/वैल्यू पेयर, उससे जुड़े AndroidDevice ऑब्जेक्ट पर सेट किए गए हैं. अगर कॉन्फ़िगरेशन, AndroidDevice एट्रिब्यूट में तय किए गए पैरामीटर को बदलने की कोशिश करता है, तो ControllerError गड़बड़ी का मैसेज दिखता है.
"AndroidDevice": [{"serial": "XXXXXX", "label": "publisher"},
{"serial": "YYYYYY", "label": "subscriber", "user_parameter_1": "anything"}]
इसके बाद, टेस्ट स्क्रिप्ट में फ़िल्टर फ़ंक्शन का इस्तेमाल करके सही डिवाइस को वापस पाया जा सकता है. साथ ही, डिवाइस ऑब्जेक्ट से अतिरिक्त पैरामीटर ऐक्सेस किए जा सकते हैं:
def setup_class(self):
self.pub = next(filter(lambda ad: ad.label == 'publisher',
self.android_devices))
self.sub = next(filter(lambda ad: ad.label == 'user_parameter_1',
self.android_devices))
वैकल्पिक पैरामीटर
यहां दिए गए पैरामीटर का इस्तेमाल करना ज़रूरी नहीं है:
adb_logcat_param: adb लॉग इकट्ठा करने के लिए,adb logcatकमांड में जोड़ी गई एक स्ट्रिंग. डिफ़ॉल्ट रूप से,adb logcat -v threadtime -b allका इस्तेमाल किया जाता है. अगरadb_logcat_paramसेट है, तो-b allसेक्शन ओवरराइट हो जाता है. उदाहरण के लिए,adb_logcat_paramको-b radioपर सेट करने से कमांडadb logcat -v threadtime -b radioपर बदल जाता है.