כתיבת רכיב הרצה במבחןטרי

בדף הזה נסביר איך לכתוב רכיב חדש של הרצת בדיקה ב-Trended.

רקע

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

זו לא דרישה מוקדמת לכתיבת גרסה חדשה של הרצת בדיקה; מתחרים יכולים להיות נכתבת לבדו.

מינימום מינימלי: הטמעת הממשק

המינימום המינימלי שצריך לעמוד בו כדי להיות כשיר להרצת בדיקה מהו אישור המסחר האלקטרוני הוא להטמיע ממשק IremoteTest ובפרט את השיטה run(TestInformation testInfo, ITestInvocationListener listener).

זוהי השיטה שמופעלת על ידי הרתמה כשמשתמשים בהרצת הבדיקה, בדומה ל-Java Runnable.

כל חלק באותה שיטה נחשב לחלק מהרצת הבדיקה.

דיווח על תוצאות מההרצה של הבדיקה

ה-method run בממשק הבסיס נותנת גישה לאובייקט ה-listener של מקלידים ITestInvocationListener. האובייקט הזה הוא המפתח מובנה לדיווח תוצאות מההרצה של הניסוי למסגרת.

על ידי דיווח על תוצאות מובנות, להרצת הבדיקה יש את המאפיינים הבאים:

• לדווח על רשימה נכונה של כל הבדיקות שפעלו, כמה זמן הן נמשכו ואם הם עברו בנפרד, נכשלו או מדינות אחרות.
• לדווח על מדדים שמשויכים לבדיקות, אם רלוונטי. לדוגמה זמן ההתקנה.
• התאמה לרוב הכלים בתשתית, למשל הצגת תוצאות מדדים וכו'.
• בדרך כלל קל יותר לנפות באגים, כי יש מעקב מפורט יותר של להגדיר.

עם זאת, דיווח על תוצאות מובנות הוא אופציונלי. יכול להיות שהרצה של ניסוי רוצה להעריך את מצב הריצה כולה כ'עבר' או 'נכשל' מבלי פרטים על הביצוע בפועל.

ניתן להפעיל את האירועים הבאים במאזין כדי להודיע למסגרת ההתקדמות הנוכחית של הביצוע:

• TestRunStarted: התראה על ההתחלה של קבוצה של מקרי בדיקה קשורים זה לזה.
  • testStarted: שליחת התראה על ההתחלה של מקרה בדיקה.
  • testנכשל/testignored: הודעה על שינוי המצב של מקרה הבדיקה בתהליך. נחשב מקרה בדיקה ללא שינוי מצב עבר.
  • testEnded: הודעה על סוף תרחיש הבדיקה.
• testRunנכשל: הודעה על כך שהסטטוס הכולל של קבוצת מקרי הבדיקה נכשל. הרצת בדיקה יכולה להיות אישור או נכשל ללא תלות בתוצאות מקרי הבדיקה, בהתאם היה אמור להיות. לדוגמה, קובץ בינארי שמריץ מספר מקרי בדיקה יכולים לדווח על כל מקרי הבדיקה של pass, אבל עם קוד יציאה של שגיאה (עבור כל סיבות: קבצים שדלפו וכו').
• testRunEnded: שליחת הודעה לסוף קבוצת מקרי הבדיקה.

תחזוקה והקפדה על הסדר הנכון של הקריאות החוזרות הן באחריות של מי שמיישם את הרצת הבדיקה, לדוגמה הפונקציה testRunEnded מופעלת במקרה של חריג באמצעות תנאי finally.

קריאות חוזרות (callback) של מקרי בדיקה (testStarted, testEnded וכו') הן אופציונליות. בדיקה עשויה להתרחש ללא מקרי בדיקה.

ייתכן שתבחינו שהמבנה הזה של אירועים מבוסס על מבנה רגיל של JUnit. המטרה היא לשמור על פיתוח קרוב לדברים בסיסיים שמפתחים בדרך כלל ידע עליהם.

דיווח על יומנים מהרצת הבדיקה

אם אתם כותבים מחלקת בדיקה או הרצה משלכם ב-TrendF, עליכם IremoteTest ומקבלים ITestInvocationListener דרך ה-method run(). המאזינים האלה יכול לשמש לרישום קבצים באופן הבא:

    listener.testLog(String dataName, LogDataType type_of_data, InputStreamSource data);

בדיקה באמצעות מכשיר

הממשק המינימלי שלמעלה מאפשר להריץ בדיקות פשוטות מאוד ומבודדות ולא דורשות משאבים מסוימים, כמו בדיקות יחידת Java.

כותבי בדיקות שירצו לעבור לשלב הבא של בדיקת מכשירים יצטרכו בממשקים הבאים:

• IDeviceTest שמאפשר לקבל את האובייקט ITestDevice שמייצג את המכשיר ומספק את ה-API כדי לקיים איתו אינטראקציה.
• IBuildReceiver שמאפשרות לבדיקה ליצור את האובייקט IBuildInfo שלב בניית ספק שמכיל את כל המידע והפריטי מידע שנוצרו בתהליך הפיתוח (Artifact) שקשורים להגדרת הבדיקה.

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

בדיקה באמצעות מספר מכשירים

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

כדי לכתוב רכיב הרצה לבדיקה שיכול להשתמש במספר מכשירים, צריך כדי ליישם את המדיניות IMultiDeviceTest כך נוכל לקבל מפה של ITestDevice אל IBuildInfo שמכילה את הרשימה המלאה של ייצוגי מכשירים ואת המידע שקשור ל-build שלהם.

לרכיב מגדיר מהממשק תמיד תתבצע קריאה לפני ה-method run, כך אפשר להניח שהמבנה יהיה זמין כשתתבצע קריאה אל run.

בדיקות מודעות להגדרות שלהן

ייתכן שבחלק מההטמעות של הרצת הבדיקה נדרש מידע על ההגדרה הכוללת כדי שיפעל כראוי, לדוגמה, מטא-נתונים לגבי ההפעלה, ש-target_preparer פעל לפני כן וכו'.

כדי לעשות זאת, להריץ בדיקה יש גישה לאובייקט IConfiguration שהוא חלק ממנו ומתבצע בו. לצפייה אובייקט הגדרה לקבלת פרטים נוספים.

בהטמעה של הרצת הבדיקה צריך להטמיע את IConfigurationReceiver כדי לקבל את האובייקט IConfiguration.

הרצת בדיקה גמישה

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

כך התשתית והרתמה הגדולה יותר יכולות למנף את השליטה הזו. ואת המשתמשים להריץ באופן חלקי את רכיב ההרצה של הבדיקה באמצעות סינון.

תמיכת הסינון מתוארת ITestFilterReceiver Interface, שמאפשר לקבל קבוצות של מסננים include ו-exclude עבור הבדיקות שאמורות לפעול או לא צריכות לפעול.

המוסכמה שלנו היא שבניסוי יופעל IFF, הוא תואם לאחד או יותר הפונקציה כוללת מסנני AND אינה תואמת לאף אחד ממסנני ההחרגה. אם לא, צריך לכלול ניתנים מסננים, יש להריץ את כל הבדיקות כל עוד הם לא תואמים את מסנני ההחרגה.