טיפול באפשרויות ב-Tradefed

הטיפול באפשרויות הוא הליבה של הגישה המודולרית של Trade Federation. בפרט, האפשרויות הן המנגנון שמאפשר למפתח, למשלב ולכלי להרצת בדיקות לעבוד יחד בלי לשכפל את העבודה של כל אחד מהם. במילים פשוטות, ההטמעה שלנו של טיפול באפשרויות מאפשרת למפתח לסמן חבר בכיתת Java כניתן להגדרה. בשלב הזה, אפשר להוסיף לערך של החבר הזה או לבטל אותו על ידי המשלב, ואחר כך אפשר להוסיף לו או לבטל אותו על ידי כלי ההרצה של הבדיקות. המנגנון הזה פועל עבור כל הסוגים המובנים של 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

ל-Test Runner יש גם גישה לנקודות ההגדרה האלה דרך מסוף Trade Federation. קודם כל, הם מריצים פקודה (כלומר, הגדרה וכל הארגומנטים שלה) באמצעות ההוראה run command <name> (או run <name> בקיצור). בנוסף, הם יכולים לציין רשימה של ארגומנטים שמהווים חלק מהפקודה, שיכולים להחליף או להוסיף לשדות שצוינו על ידי אובייקטים של מחזור חיים בכל הגדרה.

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

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].

למידע נוסף