Google Cloud ספריות הלקוח של Rust מספקות פונקציות עזר שמפשטות את האינטראקציה עם פעולות ממושכות (LRO). כדי לדמות את ההתנהגות של פעולות LRO בבדיקות יחידה, צריך להבין את הפרטים הבסיסיים שפונקציות העזר האלה מסתירות. במדריך הזה מוסבר איך לכתוב בדיקות יחידה לדגימה אוטומטית וידנית של LRO, כולל תרחישי שגיאה.
דרישות מוקדמות
במדריך הזה אנחנו יוצאים מנקודת הנחה שאתם מכירים את המדריכים הבאים:
בדיקת הסקרים האוטומטיים
נניח שקוד האפליקציה ממתין ל-lro::Poller::until_done() (סקר אוטומטי):
מכיוון שהאפליקציה משתמשת רק בתוצאה הסופית של ה-LRO, אין צורך לבדוק איך היא מטפלת בתוצאות ביניים של דגימה. הבדיקה יכולה להחזיר את התוצאה הסופית של ה-LRO ישירות מה-mock.
יצירת longrunning::model::Operation
נניח שאתם רוצים שהקריאה תחזיר את התשובה הבאה:
ה-stub מחזיר longrunning::model::Operation במקום BatchRecognizeResponse. אורזים את התגובה הצפויה ב-Operation::result:
מגדירים את השדה done בתור true כדי לציין ל-Poller שהפעולה הושלמה, וכך מסיימים את לולאת הסקר:
כתיבת הבדיקה
מגדירים את המבנה המדומה, שמטמיע את המאפיין
speech::stub::Speech:בבדיקה, יוצרים את המוק ומגדירים את הציפיות ממנו:
יוצרים לקוח מהדמה, קוראים לפונקציה ומאמתים את התגובה:
בדיקת סקר ידני עם מטא-נתונים זמניים
נניח שקוד האפליקציה שלכם מבצע סקר ידני ומעבד עדכונים חלקיים:
כדי לדמות את התנהגות האפליקציה כשהיא מקבלת מטא-נתונים זמניים, אפשר להחזיר פעולות שמתבצעות מהדמה.
יצירת longrunning::model::Operation
ה-RPC של BatchRecognize מחזיר תוצאות חלקיות בתור speech::model::OperationMetadata. אורזים את המטא-נתונים האלה בשדה Operation::metadata של ה-longrunning::model::Operation שמוחזר:
כתיבת הבדיקה
מגדירים את ה-struct המדומה, שמטמיע את המאפיין
speech::stub::Speechומחליף אתget_operation():בבדיקה, יוצרים את המוק ומגדירים את הציפיות ממנו כך שיחזיר תוצאות חלקיות (25%, 50%, 75%) ואחריהן את התוצאה הסופית:
חשוב לשים לב לפרטים הבאים לגבי אופן ההגדרה של הציפיות:
- קריאות RPC ראשוניות לעומת קריאות RPC עוקבות: הציפייה הראשונה מוגדרת ב-
batch_recognize(), ואילו כל הציפיות העוקבות מוגדרות ב-get_operation(). ה-RPC הראשוני שלBatchRecognizeמפעיל את ה-LRO בשרת ומחזיר מזהה פעולה בשדהname(הושמט מקוד הבדיקה כדי לקצר). מאותו רגע, ספריית הלקוח דוגמת את הסטטוס של ה-LRO באמצעות ה-RPCGetOperation. - סדר הקריאות: הציפיות נרשמות ב-
Sequence. כךmockallיכול לאמת את סדר הקריאות ולקבוע איזו ציפייה שלexpect_get_operationתואמת לכל סקר.
- קריאות RPC ראשוניות לעומת קריאות RPC עוקבות: הציפייה הראשונה מוגדרת ב-
יוצרים לקוח מהדמה, קוראים לפונקציה ומאמתים את התגובה:
הדמיית שגיאות
שגיאות יכולות להתרחש בכמה נקודות במהלך LRO.
אם האפליקציה משתמשת בסקרים אוטומטיים, כל מקורות השגיאה שווים: until_done() מחזיר את השגיאה ב-Result, בלי קשר למקור שלה.
הדמיה של שגיאה בהפעלת LRO היא הבדיקה הפשוטה ביותר.
סימולציה של שגיאה בהפעלת LRO
כדי לדמות שגיאה בהתחלה של LRO, מגדירים את הבקשה הראשונית כך שתיכשל עם שגיאה:
בדגימה ידנית, הענף PollingResult::Completed מקבל את השגיאה מהפעלת ה-LRO, שמסיימת את לולאת הדגימה:
סימולציה של LRO שגורמת לשגיאה
כדי לדמות פעולה ארוכה שנכשלת אחרי החזרת מטא-נתונים זמניים, מחזירים את השגיאה ב-longrunning::model::Operation הסופי:
הגדרת ציפיות להחזרת Operation שנכשל מ-get_operation:
בדגימה ידנית, הענף PollingResult::Completed מקבל את תוצאת השגיאה, ומסיים את לולאת הדגימה:
הדמיה של שגיאת דגימה
לולאות דגימה יכולות להסתיים גם כשמדיניות הדגימה מוצתה. במצב כזה, ספריית הלקוח לא יכולה לקבוע באופן ודאי אם ה-LRO הושלם.
אם לאפליקציה יש לוגיקה מותאמת אישית לטיפול בשגיאות דגימה, אפשר לבדוק אותה על ידי החזרת שגיאה ישירות מהציפייה של get_operation:
בסקר ידני, הענף PollingResult::PollingError מקבל את שגיאת הסקר המדומה:
קוד בדיקה מלא
בקטעים הבאים מוצג הקוד המלא של הבדיקות שמתוארות במדריך הזה.