טיפול באופציות ב-Tradefed

טיפול באופציות נמצא בלב הגישה המודולרית של Trade Federation. בפרט, האפשרויות הן המנגנון שבאמצעותו המפתח, האינטגרטור וה-Test Runner יכולים לעבוד יחד ללא צורך לשכפל את עבודתו של זה. במילים פשוטות, היישום שלנו של טיפול באופציות מאפשר למפתח לסמן חבר בכיתה של Java כניתן להגדרה, ובשלב זה הערך של אותו חבר עשוי להיות מוגדל או ידרוס על ידי האינטגרטור, ועשוי להיות מוגדל או לעקוף לאחר מכן על ידי ה-Test Runner. מנגנון זה פועל עבור כל סוגי Java, כמו גם עבור כל Map או Collection של טיפוסים פנימיים.

הערה: מנגנון הטיפול באופציות פועל רק עבור מחלקות המטשמות את אחד מהממשקים הכלולים במחזור החיים של הבדיקה , ורק כאשר המחלקה הזו מופעלת על ידי מנגנון מחזור החיים.

מפתח

כדי להתחיל, המפתח מסמן חבר עם ההערה @Option . הם מציינים (לכל הפחות) את ערכי name description , המציינים את שם הארגומנט המשויך לאותה אפשרות, ואת התיאור שיוצג במסוף TF כאשר הפקודה מופעלת עם --help או --help-all .

כדוגמה, נניח שאנו רוצים לבנות מבחן טלפון פונקציונלי אשר יחייג מגוון מספרי טלפון, ונצפה לקבל רצף של צלילי DTMF מכל מספר לאחר שיתחבר.

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 כרגיל, מבלי לשים לב הרבה לעובדה שהם ניתנים להגדרה. מכיוון ששדות ה- @Option מוגדרים לאחר שהמחלקה מופעלת, אך לפני קריאת שיטת run , זה מספק דרך קלה למימושים להגדיר ברירת מחדל עבור או לבצע סוג של סינון בשדות Map Collection , אשר מצורפים אחרת- רק.

אינטגרטור

האינטגרטור עובד בעולם הקונפיגורציות, שנכתבות ב-XML. פורמט התצורה מאפשר לאינטגרטור להגדיר (או להוסיף) ערך עבור כל שדה @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. בראש ובראשונה, הם יפעילו Command (כלומר, config וכל הארגומנטים שלה) עם הפקודה run command <name> (או run <name> בקיצור). מעבר לכך, הם יכולים לציין כל רשימה של ארגומנטים שהם חלק מהפקודה, אשר עשויה להחליף או לצרף לשדות שצוינו על ידי Lifecycle Objects בתוך כל תצורה.

כדי להפעיל את מבחן השהייה הנמוכה עם מספרי טלפון many-numbers , ה-Test Runner יכול לבצע:

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

לחלופין, כדי לקבל אפקט דומה מהכיוון ההפוך, ה-Test Runner יכול להפחית את זמן ההמתנה למבחן many-numbers :

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

הזמנת אופציות

--call שתבחין כי אפשרות call העומדת בבסיס ההטמעה היא Map , כך שבקריאה חוזרת בשורת הפקודה כולם יאוחסנו.

timeout לאפשרות, שיש לו יישום בסיסי של long , יכול לאחסן רק ערך אחד. אז רק הערך האחרון שצוין יישמר. --timeout 5 --timeout 10 יביא timeout המכיל 10.

במקרה של List או Collection כיישום הבסיסי, כל הערכים יאוחסנו, בסדר המצוין בשורת הפקודה.

אפשרויות בוליאניות

ניתן להגדיר אופציות מסוג בסיס בוליאני כ- true על ידי העברה ישירה של שם האופציה, לדוגמה, --[option-name] וניתן להגדיר אותן ל- false באמצעות התחביר --no-[option-name] .

ראה גם

העברת אפשרויות לסוויטה ולמודולים