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

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

ראו בנוסף

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