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

מתוך ויקיפדיה, האנציקלופדיה החופשית

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

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

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

תוכן עניינים 1 דרישות קדם 2 מחזור הפיתוח 2.1 יצירת בדיקה 2.2 וידוא שהבדיקה החדשה נכשלת 2.3 כתיבת הקוד הנבדק 2.4 וידוא שהבדיקה החדשה מצליחה 2.5 ארגון הקוד מחדש 3 רכיבי דמי 4 ראו גם 5 מקורות 6 קישורים חיצוניים

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[עריכה] רכיבי דמי

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

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

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

[עריכה] ראו גם

• FIT
• JUnit

[עריכה] מקורות

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

[עריכה] קישורים חיצוניים

• כתיבת בדיקות לפני קוד (אתר extremeprogramming.org, באנגלית)