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

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

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

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

2. נוכל לפתוח חשבונות בדיקה ב S3 ובשרת שליחת המיילים. אחרי זה נוכל לכתוב קוד שידע לקרוא מידע מ S3 וקוד אחר שיידע לקרוא מיילים נכנסים ובעזרתם לבדוק שהרצף שתיארתי למעלה באמת עובד.

3. נוכל להחליף את S3 ואת שרת המיילים ב Mock Objects במערכת מהם יהיה לנו הרבה יותר קל לקרוא את המידע ולראות שהמידע אכן התקבל ונשלח כמו שצריך.

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

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

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

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

אל תשברו את השיניים בשביל לבדוק מנגנונים שקשה לבדוק. עדיף לכתוב במקומם מנגנונים שקל לבדוק ולהמשיך משם.