טיפול באפשרויות ב-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 מוגדרים אחרי יצירת המופע של הכיתה, אבל לפני הקריאה ל-method‏ 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, אפשר להריץ את הקוד הבא ב-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 שמשמשת כבסיס להטמעה היא Map, כך שכאשר מריצים --call שוב ושוב בשורת הפקודה, כולן מאוחסנות.

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

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

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

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

למידע נוסף