פיתוח מונחה-בדיקות

מתוך ויקיפדיה, האנציקלופדיה החופשית
קפיצה אל: ניווט, חיפוש
הנדסת תוכנה
מאמר זה הוא חלק מקטגוריית הנדסת תוכנה

Coding Shots Annual Plan high res-5.jpg
מתכנת בעבודתו

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

Crystal Clear | Scrum | Unified Process | Extreme Programming | Continuous integration

תחומים תומכים
ניהול פרויקטים | ניהול תצורה | תיעוד | הבטחת איכות | Profiling
כלים
מהדר | מקשר | IDE | ניהול גרסאות | אוטומציית בנייה

פיתוח מונחה-בדיקות (test driven development ובקיצור TDD) היא מתודולוגיית פיתוח תוכנה שבה נכתבת בדיקת יחידה בטרם נכתב הקוד אותו היא בודקת. בפיתוח בשיטה זו בדיקת היחידה נכתבת תמיד באמצעות חבילת תוכנה המיועדת להרצה אוטומטית של בדיקות היחידה (כגון JUnit). בדיקות יחידה לא הוגדרו לראשונה בשיטת פיתוח מונחה-בדיקות, אך בשיטה זו הן נתונות לקבוצת הנחיות מוגדרות היטב.

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

דרישות קדם[עריכת קוד מקור | עריכה]

דרישה מרכזית בפיתוח מונחה-בדיקות היא שימוש בחבילת תוכנה תשתיתית ליישום בדיקות יחידה. חבילה זו מורכבת מספריות המצטרפות לקוד הבדיקה ובדרך כלל גם מתוכניות שרות המאפשרות את הרצת הבדיקות שנכתבו באופן אוטומטי. ספריות התוכנה של החבילה יכילו פרוצדורות לבדיקת טענות נכוֹ‏נוּ‏ת בקוד הבדיקה (Assertions). כל עוד הפרוצדורות הללו מחזירות אמת, הבדיקה מסיימת בהצלחה וכאשר פרוצדורה כלשהי נכשלת, הבדיקה מסיימת בכישלון.

מחזור הפיתוח[עריכת קוד מקור | עריכה]

ייצוג גרפי למחזור הפיתוח בשיטת TDD

להלן השלבים במחזור הפיתוח של בדיקת יחידה בודדת כפי שהוצעו בספר "פיתוח מונחה-בדיקות על פי דוגמה" של קנט בק[1]. המחזורים מיושמים עבור כל תכונה נדרשת ביישום, פעם אחר פעם עד לסיום מימוש התכונות. יש לשים לב שמספר השינויים הנוספים לקוד במעבר מאיטרציה אחת לשנייה צריך להיות קטן (עד עשרה צעדי עריכה).

יצירת בדיקה[עריכת קוד מקור | עריכה]

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

וידוא שהבדיקה החדשה נכשלת[עריכת קוד מקור | עריכה]

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

כתיבת הקוד הנבדק[עריכת קוד מקור | עריכה]

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

וידוא שהבדיקה החדשה מצליחה[עריכת קוד מקור | עריכה]

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

ארגון הקוד מחדש[עריכת קוד מקור | עריכה]

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

רכיבי דמי[עריכת קוד מקור | עריכה]

הרצת כלל בדיקות היחידה של המפתח או של היישום כולו מחייבת ברוב המקרים שימוש ברכיבי דמי (Mock objects). תפקיד רכיבים אלה הוא להחליף רכיבים אמיתיים שהקוד הנבדק תלוי בהם. ההחלפה מתאפשרת לרוב באמצעות שימוש בממשק משותף שהרכיב האמיתי ורכיב הדמי מממשים. לצורך מימוש רכיבי דמי נעזרים חבילות תוכנה ייעודיות.

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

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

יתרונות השיטה[עריכת קוד מקור | עריכה]

  1. מחקר שבוצע בשנת 2005 מצא כי מפתחים שהשתמשו במתודולוגיית ה-TDD היו בעלי נטייה להיות יותר יצרניים במהלך עבודתם. כמו כן פותחה השערה שקושרת בין איכות הקוד לבין השימוש בשיטה.
  2. מתכנתים המשתמשים בשיטה זאת בפרויקטים חדשים דיווחו כי הם מרגישים פחות צורך להשתמש בכלים לניפוי הקוד (Debugger).
  3. פיתוח בשיטת ה-TDD, בנוסף להיותו כלי שמאפשר אימות ונכונות הקוד, יכול להוביל לעיצוב טוב יותר של הקוד הנכתב. דבר זה נובע מכך ששיטה זאת ממקדת את תשומת לבו של המפתח למקרי השימוש השונים של המערכת לפני כתיבת קוד המימוש.
  4. באמצעות שיטה זאת קיימת סבירות גבוהה יותר שכל מסלולי הבדיקה כוסו לפחות על ידי מקרה בדיקה אחד, דבר אשר נותן למתכנת רמת אמינות גבוהה יותר של ביצועי הקוד.
  5. כתיבה בשיטה זאת יכולה להוביל לקוד יותר מודולרי, גמיש ונוח לשינויים.

חסרונות השיטה[עריכת קוד מקור | עריכה]

  1. שיטה זאת קשה לשימוש במצבים בהם נדרשת בדיקה פונקציונלית מלאה על מנת לקבוע הצלחה או כישלון של מקרי הבדיקה. דוגמה לכך הם מערכות user interface אשר עובדים עם בסיס נתונים ומערכות תקשורת בעלי קונפיגורציה מיוחדת.
  2. הצלחת הטמעת השיטה בארגון תלוי בקבלת התמיכה של הדרג הניהולי. ללא האמונה הארגונית המלאה בכך שהשיטה תגרום לשיפור המוצר, הדרג הניהולי של הארגון יכול לקבל את התחושה שהזמן שהושקע בכתיבת מקרי הבדיקה המקדמים היה בזבוז של זמן.
  3. בדיקות יחידה הנכתבות בשיטת ה-TDD נכתבות על ידי המתכנת שיממש את קוד הפיתוח ולא על ידי גורם חיצוני אחר, דבר אשר יכול להוביל לכישלון במציאת תקלות הנובעות ממחשבה לא נכונה של אותו האדם.
  4. כתיבת קוד הבדיקה מוסיפה על תקורת העומס של ניהול הפרויקט.

הצלחת השיטה[עריכת קוד מקור | עריכה]

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

בשנים 2009-‏2010 בוצע מחקר מקיף על יעילות השיטה בקרב צוותי פיתוח בחברות IBM ו-Microsoft שהשתמשו בטכניקת ה-TDD. על פי תוצאות המחקר צוותים שעבדו בשיטת פיתוח זו דיווחו כי כמות התקלות בקוד ירדה בין 40 ל-90 אחוזים לעומת צוותים מקבילים שלא השתמשו בשיטה, אולם חשוב לציין כי זמן הפיתוח הראשוני לאחר אימוץ השיטה עלה בין 15 ל-35 אחוזים.

ראו גם[עריכת קוד מקור | עריכה]

קישורים חיצוניים[עריכת קוד מקור | עריכה]

הערות שוליים[עריכת קוד מקור | עריכה]

  1. ^ Test Driven Development: By Example, מאת קנט בק, הוצאת Addison-Wesly Longman, שנת 2002