Tradefed में विकल्प मैनेज करना

विकल्पों को मैनेज करने की सुविधा, ट्रेड फ़ेडरेशन के मॉड्यूलर अप्रोच का मुख्य हिस्सा है. खास तौर पर, विकल्प एक ऐसा तरीका है जिसकी मदद से डेवलपर, इंटिग्रेटर, और टेस्ट रनर साथ मिलकर काम कर सकते हैं. इसके लिए, उन्हें एक-दूसरे के काम को डुप्लीकेट करने की ज़रूरत नहीं होती. आसान शब्दों में कहें, तो विकल्प हैंडल करने की सुविधा लागू करने से डेवलपर, Java क्लास के किसी सदस्य को कॉन्फ़िगर करने के तौर पर मार्क कर सकता है. इसके बाद, इंटिग्रेटर उस सदस्य की वैल्यू को बढ़ा या बदल सकता है. साथ ही, टेस्ट रनर उस वैल्यू को बढ़ा या बदल सकता है. यह तरीका, सभी Java इंट्रिंसिक टाइप के साथ-साथ, इंट्रिंसिक टाइप के किसी भी Map या Collection इंस्टेंस के लिए काम करता है.

ध्यान दें: विकल्प को हैंडल करने का तरीका सिर्फ़ उन क्लास के लिए काम करता है जो टेस्ट लाइफ़साइकल में शामिल इंटरफ़ेस में से किसी एक को लागू करती हैं. साथ ही, यह सिर्फ़ तब काम करता है, जब उस क्लास को लाइफ़साइकल मशीनरी से इंस्टैंटिएट किया जाता है.

डेवलपर

शुरुआत में, डेवलपर किसी सदस्य को @Option एनोटेशन के साथ मार्क करता है. ये कम से कम name और description वैल्यू तय करते हैं. name वैल्यू से, उस विकल्प से जुड़े आर्ग्युमेंट का नाम तय होता है. वहीं, description वैल्यू से वह ब्यौरा तय होता है जो --help या --help-all के साथ कमांड चलाने पर, TF कंसोल पर दिखता है.

उदाहरण के लिए, मान लें कि हमें एक ऐसा फ़ोन टेस्ट बनाना है जो अलग-अलग फ़ोन नंबर डायल करता है. साथ ही, कनेक्ट होने के बाद हर नंबर से डीटीएमएफ़ टोन का क्रम पाने की उम्मीद करता है.

public class PhoneCallFuncTest extends IRemoteTest {
    @Option(name = "timeout", description = "How long to wait for connection, in millis")
    private long mWaitTime = 30 * 1000;  // 30 seconds

    @Option(name = "call", description = "Key: Phone number to attempt. " +
            "Value: DTMF to expect. May be repeated.")
    private Map<String, String> mCalls = new HashMap<String, String>;

    public PhoneCallFuncTest() {
        mCalls.add("123-456-7890", "01134");  // default
    }

डेवलपर को उस टेस्ट के लिए, कॉन्फ़िगरेशन के दो पॉइंट सेट अप करने के लिए बस इतना ही करना होगा. इसके बाद, वे सामान्य तरीके से mWaitTime और mCalls का इस्तेमाल कर सकते हैं. उन्हें इस बात पर ज़्यादा ध्यान देने की ज़रूरत नहीं है कि इन्हें कॉन्फ़िगर किया जा सकता है. ऐसा इसलिए, क्योंकि क्लास को इंस्टैंटिएट करने के बाद, लेकिन run तरीके को कॉल करने से पहले @Option फ़ील्ड सेट किए जाते हैं. इससे लागू करने वालों को Map और Collection फ़ील्ड के लिए डिफ़ॉल्ट वैल्यू सेट अप करने या किसी तरह का फ़िल्टर करने का आसान तरीका मिलता है. ऐसा न होने पर, इन फ़ील्ड में सिर्फ़ वैल्यू जोड़ी जा सकती हैं.

इंटिग्रेटर

इंटिग्रेटर, कॉन्फ़िगरेशन की दुनिया में काम करता है. ये कॉन्फ़िगरेशन, एक्सएमएल में लिखे जाते हैं. कॉन्फ़िगरेशन फ़ॉर्मैट की मदद से, इंटिग्रेटर किसी भी @Option फ़ील्ड के लिए वैल्यू सेट कर सकता है या उसे जोड़ सकता है. उदाहरण के लिए, मान लें कि इंटिग्रेटर को कम इंतज़ार के समय वाला ऐसा टेस्ट तय करना है जो डिफ़ॉल्ट नंबर के साथ-साथ कई नंबरों पर कॉल करता हो. वे कॉन्फ़िगरेशन का एक ऐसा पेयर बना सकते हैं जो इस तरह दिख सकता है:

<?xml version="1.0" encoding="utf-8"?>
<configuration description="low-latency default test; low-latency.xml">
    <test class="com.example.PhoneCallFuncTest">
        <option name="timeout" value="5000" />
    </test>
</configuration>

<?xml version="1.0" encoding="utf-8"?>
<configuration description="call a bunch of numbers; many-numbers.xml">
    <test class="com.example.PhoneCallFuncTest">
        <option name="call" key="111-111-1111" value="#*#*TEST1*#*#" />
        <option name="call" key="222-222-2222" value="#*#*TEST2*#*#" />
        <!-- ... -->
    </test>
</configuration>

टेस्ट रनर

Test Runner के पास, Trade Federation console के ज़रिए इन कॉन्फ़िगरेशन पॉइंट का ऐक्सेस भी होता है. सबसे पहले, वे run command <name> निर्देश (या छोटे रूप में run <name>) के साथ एक कमांड (यानी कि कॉन्फ़िगरेशन और उसके सभी तर्क) चलाते हैं. इसके अलावा, वे यह तय कर सकते हैं कि कमांड में कौनसे आर्ग्युमेंट शामिल किए जाएं. ये आर्ग्युमेंट, हर कॉन्फ़िगरेशन में लाइफ़साइकल ऑब्जेक्ट के ज़रिए तय किए गए फ़ील्ड को बदल सकते हैं या उनमें जोड़े जा सकते हैं.

many-numbers फ़ोन नंबरों के साथ कम समय में होने वाले टेस्ट को चलाने के लिए, Test Runner यह कोड एक्ज़ीक्यूट कर सकता है:

tf> run low-latency.xml --call 111-111-1111 #*#*TEST1*#*# --call 222-222-2222 #*#*TEST2*#*#

इसके अलावा, अगर टेस्ट रनर को विपरीत दिशा से ऐसा ही इफ़ेक्ट चाहिए, तो वह many-numbers टेस्ट के लिए इंतज़ार का समय कम कर सकता है:

tf> run many-numbers.xml --timeout 5000

विकल्पों को क्रम से लगाना

आपको दिख सकता है कि call विकल्प को लागू करने के लिए, Map का इस्तेमाल किया जाता है. इसलिए, कमांड लाइन पर बार-बार --call करने पर, ये सभी सेव हो जाते हैं.

timeout विकल्प में long का इस्तेमाल किया जाता है. इसमें सिर्फ़ एक वैल्यू सेव की जा सकती है. इसलिए, सिर्फ़ आखिरी वैल्यू सेव की जाती है. --timeout 5 --timeout 10 के नतीजों में timeout में मौजूद 10 शामिल हैं.

List या Collection को लागू करने पर, सभी वैल्यू को कमांड लाइन पर दिए गए क्रम में सेव किया जाता है.

बूलियन विकल्प

बूलियन अंडरलाइंग टाइप के विकल्पों को सीधे तौर पर विकल्प का नाम पास करके, true पर सेट किया जा सकता है. उदाहरण के लिए, --[option-name]. साथ ही, इन्हें false पर सेट करने के लिए, --no-[option-name] सिंटैक्स का इस्तेमाल किया जा सकता है.

यह भी देखें: