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

1. מתי לכתוב את הבדיקה?

2. מה לבדוק?

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

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

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