טיפול באופציות נמצא בלב הגישה המודולרית של 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]
.