TDD - סיפור ניצחון
כתבתי בדיקת אינטגרציה בין לוגיקה חדשה שכתבתי לבין מחלקה קיימת בשם DBLoader אשר אחראית על טעינה מ DB ובנייה של מבנה נתונים.
DBLoader נכתב ונבדק לפני הרבה זמן. הלוגיקה החדשה נבדקה ע"י בדיקות יחידה. לכן מאוד התפלאתי כשהבדיקה נכשלה.
גיליתי ע"י דיבוג ש DBLoader מחזיר לי תוצאה לא נכונה. אבל DBLoader כבר כתוב ובדוק הרבה זמן . מסתבר שלא היו בדיקות של פרויקטים שמכילים תתי פרויקטים ולכן loadSubProjects בכלל לא השפיע על ה flow של DBLoader בבדיקות. בדיקת האינטגרציה שכתבתי הייתה הלקוח הראשון בו loadSubProjects כן היה חלק מה flow.
אז כתבתי בדיקה עם אותו תרחיש עבור DBLoader. הבדיקה נכשלה, פתרתי את הבאג, שתי הבדיקות עברו. הכל סבבה 😎
מאחר והבנתי ש DBLoader לא נבדק עם תרחישים רלוונטיים עבור הפרמטר loadSubProjects החלטתי לעבות את הבדיקות של DBLoader למרות שבדיקת האינטגרציה שלי כבר עברה.
חיפשתי איזה בדיקות אני יכולה להוסיף , מאחר והקוד היה כבר כתוב ניסיתי להבין איפה הקוד יכול להישבר מקריאה שלו ולפי זה לכתוב בדיקות. לא הצלחתי למצוא איזה בדיקות לכתוב, לא רואה שום סיבה שהקוד יישבר.
ואז עצרתי את עצמי ואמרתי רגע זה לא הדרך שבה אני כותבת בדיקות בד"כ. אני בד"כ מתחילה מלחשוב על תוכנית בדיקות: חושבת על המימדים של הבעיה , על הערכים של כל מימד ובוחרת קומבינציות בין המימדים והערכים שלהם (מאחר ולבדוק את כל הקומבינציות זה אין סופי). כלומר עובדת TDD.
אתם מוזמנים לנחש: מצאתי באג! 😁 באג טיפשי לחלוטין שכנראה נבע מריפקטור. DBLoader העביר false אל recursiveLoading במקום את loadSubProjects.
DBLoader {
public ProjectTree Load(ObjectIdentifier projectId,bool loadSubProjects);
}
DBLoader נכתב ונבדק לפני הרבה זמן. הלוגיקה החדשה נבדקה ע"י בדיקות יחידה. לכן מאוד התפלאתי כשהבדיקה נכשלה.
גיליתי ע"י דיבוג ש DBLoader מחזיר לי תוצאה לא נכונה. אבל DBLoader כבר כתוב ובדוק הרבה זמן . מסתבר שלא היו בדיקות של פרויקטים שמכילים תתי פרויקטים ולכן loadSubProjects בכלל לא השפיע על ה flow של DBLoader בבדיקות. בדיקת האינטגרציה שכתבתי הייתה הלקוח הראשון בו loadSubProjects כן היה חלק מה flow.
אז כתבתי בדיקה עם אותו תרחיש עבור DBLoader. הבדיקה נכשלה, פתרתי את הבאג, שתי הבדיקות עברו. הכל סבבה 😎
מאחר והבנתי ש DBLoader לא נבדק עם תרחישים רלוונטיים עבור הפרמטר loadSubProjects החלטתי לעבות את הבדיקות של DBLoader למרות שבדיקת האינטגרציה שלי כבר עברה.
חיפשתי איזה בדיקות אני יכולה להוסיף , מאחר והקוד היה כבר כתוב ניסיתי להבין איפה הקוד יכול להישבר מקריאה שלו ולפי זה לכתוב בדיקות. לא הצלחתי למצוא איזה בדיקות לכתוב, לא רואה שום סיבה שהקוד יישבר.
ואז עצרתי את עצמי ואמרתי רגע זה לא הדרך שבה אני כותבת בדיקות בד"כ. אני בד"כ מתחילה מלחשוב על תוכנית בדיקות: חושבת על המימדים של הבעיה , על הערכים של כל מימד ובוחרת קומבינציות בין המימדים והערכים שלהם (מאחר ולבדוק את כל הקומבינציות זה אין סופי). כלומר עובדת TDD.
אתם מוזמנים לנחש: מצאתי באג! 😁 באג טיפשי לחלוטין שכנראה נבע מריפקטור. DBLoader העביר false אל recursiveLoading במקום את loadSubProjects.
DBLoader{
public ProjectTree Load(ObjectIdentifier projectId,bool loadSubProjects)}
...
var projectTree = WorkitemsLoader.Load(projectId , false loadSubProjects);
....
}
}
WorkitemsLoader{
public ProjectTree Load(ObjectIdentifier projectId , bool recursiveLoading){
.....
}
}
נראה שההרגל לכתוב בדיקות לפני שמודעים למימוש ממש משפיע על בחירה של הבדיקות שאנחנו כותבים ולכן כמובן איזה באגים נמצא.