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