איך כותבים מבחני יחידות?
מבחני יחידות הם דרך טובה לבדוק תוכניות תוך כדי פיתוחן. כדי לכתוב אותם, יהיה עליכם לפרק את התוכנית שלכם ליחידות עצמאיות, וליצור מבחנים שבודקים כל יחידה אחת אחת בצורה מבוקרת. נתח את התוצאות שלך והשתמש בהן לשיפור קוד התוכנית שלך. אף על פי שאף מבחן לא יכול לבדוק את כל הבאגים הפוטנציאליים, הפעלת בדיקות יעילות ליחידה תסייע להבטיח שהתוכנית שלך תפעל כמצופה.
חלק 1 מתוך 3: תכנון מבחני יחידות
- 1ממפה את התוכנית שלך ליחידות. ההיבט המרכזי במבחן יחידה טוב הוא שהוא בודק רק חלק אחד בתוכנית. בין אם אתם מעוניינים לבדוק תוכנית קיימת ובין אם אתם מתכננים מבחנים לתוכנית שעדיין לא כתובה, יהיה עליכם לפרק אותה לחלקים בדידים ("יחידות"). לאחר מכן תכתוב מבחן יחידה לכל אחד.
- ההגדרה של "יחידה" משתנה מאוד בהתאם לסוג התוכנית שאתה מפתח. יחידה יכולה להיות מחלקה, אך גם פונקציה או הליך יחיד.
- 2קבע אם אתה זקוק לבדיקות מבוססות מדינה או אינטראקציה. ניתן להשתמש במבחן יחידה לבדיקת שני סוגים של תרחישים. נעשה שימוש בבדיקות ממלכתיות כדי לראות אם יחידת תכנית מניבה תוצאות ראויות או צפויות. לעומת זאת, נעשה שימוש בבדיקות מבוססות אינטראקציה כדי לראות אם יחידה מגדירה שיטות צפויות לפעולה. כדי לכתוב מבחן טוב, תצטרך לזהות את מה שאתה מנסה לבדוק, לכן זכור אחת הגישות הללו כמודל.
- 3תכנן מבחנים פשוטים וקריאים. זכור כי תצטרך לכתוב המון המון מבחני יחידות. אתה רוצה להריץ בדיקת יחידה עבור כל חלק בתוכנית שלך. לשמור על פשטות הבדיקות שלך יהיו מספר יתרונות:
- בדיקות פשוטות יסייעו להבטיח שבאמת בודקים יחידה אחת בכל פעם.
- קוד המבחנים יהיה אמין. אם יש לך קוד בדיקה מורכב, הוא יהיה נוטה יותר לבעיות, וכך יהיה קשה יותר לראות באגים בקוד התוכנית שאתה בודק.
- הבדיקות יהיו מהירות יותר, ותקטין את משך הזמן הכולל שלוקח לבצע את הבדיקה.
- מבחן פשוט יהיה קריא, כלומר ייתכן שתראה כמה בעיות אפשריות רק על ידי הסתכלות על הקוד עצמו.
- 4בידול מבחני יחידות ממבחני אינטגרציה. מפתחים מנוסים יודעים שיש דרכים שונות לבחון תוכנית. מבחני היחידות הם צרים, ספציפיים, ורואים רק חלק אחד בתוכנית. לעומת זאת, מבחני אינטגרציה בוחנים את התוכנית כולה בסביבה אמיתית. במילים אחרות, בדיקות יחידות מבטיחות שהחלקים הבודדים בתכנית יעבדו, בעוד שבדיקת שילוב מאמתת שהחלקים עובדים יחד.
- מבחני אינטגרציה דורשים בדרך כלל אלמנטים חיצוניים, כמו שרתי אינטרנט או מסד נתונים. כדי לשמור על שליטת בדיקות היחידה, כתוב אותם כך שלא יזדקקו לאלמנטים חיצוניים.
חלק 2 מתוך 3: שימוש בגישה לסדר, לפעול, לטעון (AAA)
- 1קבע את הנתונים הדרושים לך כדי להריץ את הבדיקה. כדי להריץ בדיקת יחידה בפועל, תצטרך קלט, אך זה יכול להשתנות במידה רבה בהתאם לסוג התוכנית שאתה מפתח. דוגמאות נפוצות כוללות כמה משתנים או רשימת נתונים (כגון קבוצת מספרים).
- אתה יכול לנסות להריץ את בדיקת היחידה שלך עם נתונים ממש פשוטים, או "נתוני דמה". זה יכול לעזור לך להעריך במהירות אם היחידה עובדת טוב.
- 2אתחל את היחידה שברצונך לבדוק. הגדר זאת כך שיקרה באמצעות פרוטוקול קוד האתחול עבור שפת התכנות בה אתה משתמש. שלב זה מכונה החלק "סידור" בגישת AAA. החלק של התוכנית שאתה בודק מכונה System Under Test (SUT).
- לדוגמה, אתה יכול לאתחל יחידה שמבצעת חשבון כלשהו על קבוצה של מספרים.
- 3השתמש במערכת הנבדקת (SUT). החלק הבא של מבחן היחידה שלך צריך לבקש מהיחידה "לפעול". מה שאתה מבקש מהבדיקה יהיה תלוי בשפה ובסוג התוכנית, אך בדרך כלל הבדיקה תעשה משהו כמו להפעיל שיטה עבור ה- SUT.
- לדוגמה, הפעולה המבוקשת עשויה להיות מתן סכום של קבוצת מספרים.
- 4שימו לב להתנהגות התוכנית. תצטרך שבדיקת היחידה תכלול היבט ש"יבטא "אם התוכנית שאתה בודק פועלת כראוי. מתוך מחשבה על התוצאה הצפויה, כתוב את מבחן היחידה שלך כך שהוא "יעבור" אם הדברים יעבדו כמצופה, ו"יכשלו "אם לא.
- לדוגמא, אם תרצה שיחידה תיתן את הסכום של המספרים הזוגיים בלבד מתוך קבוצה, תצפה שהסכום יהיה גם מספר זוגי. אם היחידה נותנת מספר אי זוגי כתוצאה מכך, היא נכשלה במבחן.
- 5ניתוח התוצאות. לאחר שהמבחן עבר את דרכו, תורכם לפרש את מה שקרה. האם זה עבר או נכשל? איתור כשל מציין שיש בעיה בקוד התוכנית שלך שיש לתקן. מכיוון שאתה פשוט עובד עם יחידה אחת בכל פעם, אם יהיה קל יותר לבודד היכן הבעיה עשויה להיות.
- אם ה- SUT ההיפותטי שלך מהדוגמה הקודמת סיפק סכום אי זוגי במקום אחד, למשל, אתה יכול לבדוק את הקוד שהפיק את הסכום, כמו גם את הקוד שאחזר את המספרים הזוגיים מהסט, כדי לראות היכן השגיאה היא.
- 6התנסו בנתונים גרועים. מפתחים מומחים ממליצים לנסות זאת עם מבחני היחידות שלכם. מנקודת מבט מדעית למהדרין, קיום תוכנית לעשות בדיוק את מה שציפית לא מוכיח שהיא אכן תפעל. ניסיון לנתונים גרועים יראה שהתוכנית תזהה בעיות ותגיב בהתאם.
- בהמשך לדוגמה הקודמת: אם ה- SUT שלך מייצר סכומים שווים, זה לא בהכרח מוכיח שהוא פועל כראוי - זה אולי רק נותן סכומי שווא. נסה את בדיקת היחידה עם נתונים גרועים, כמו קבוצה של מספרים שלמים מוזרים בלבד. על התוכנית לציין שהיא לא יכולה לייצר את סכום המספרים השווים בערכה משום שלא היו כאלה בערכה.
- אם אתה מכניס נתונים גרועים והבדיקה גורמת לכך ששום דבר לא בסדר (למשל, הוא עדיין מספק סכום), אז אתה יודע שיש בעיה ביחידה (למשל, אולי הקוד משיג מספרים אי זוגיים במקום אפילו כאלה).
חלק 3 מתוך 3: כתיבת קוד לבדיקה
- 1כתוב את המבחן לפני שאתה כותב את הקוד. זה אולי נראה לא אינטואיטיבי, אך מפתחים נשבעים שהדרך היא לכתוב קוד כדי לעבור מבחן יחידה, במקום להשתמש בבדיקות יחידה כדי לראות אם קוד יעבוד. זו יכולה להיות הגישה שיש לקחת אם בעצם לא התחלת לכתוב את הקוד שלך, או אם עדיין אין לך הרבה. היה ממוקד מטרה: כתוב את מבחני היחידות שלך כדי לבדוק אם הקוד יעשה את המצופה, ואז כתוב את הקוד ואז בדוק אותו.
- כתיבת המבחנים תחילה מעודדת אותך לכתוב מספיק מספיק קוד בכדי לגרום לתוכנית לעשות את מה שהיא צריכה, מבלי לכלול בשוגג קוד מיותר או רע.
- 2בוא עם בדיקות יחידה בזמן שאתה כותב קוד, אם אתה צריך. אם אתה בדרך בדרך עם כתיבת התוכנית שלך, אתה עדיין יכול לעשות שימוש במבחני יחידות. פשוט צייר על המפה שעשית מהתוכנית שלך כדי לפרק אותה ליחידות בודדות. הפעל את הבדיקות בגישת AAA והתאם את הקוד שלך לפי הצורך בהתבסס על תוצאות הבדיקה.
- 3כתוב קוד לבדיקה. אחד הדברים הקשים ביותר בשימוש בגישת בדיקת היחידות בפיתוח התוכנית הוא שעליך לתכנן בקפידה שיהיה לך קוד שניתן לבדוק בפועל. אם התוכנית שלך מלאה באלמנטים שאינך יכול לבדוק בפועל, לא תוכל להשתמש בשיטת בדיקת היחידה כדי לוודא שהתוכנית שלך תפעל כצפוי. זכור זאת כשאתה כותב קוד עבור התוכנית שלך.
- לדוגמה, הימנע מדברים כמו תשומות נסתרות וגורמים שאינם דטרמיניסטיים בקוד התוכנית שלך.
- אם אתה רוצה מדריכים ספציפיים בנושא שיטות עבודה מומלצות בכתיבת מבחני יחידות עבור שפת תכנות מסוימת, חיפוש מהיר באינטרנט אמור להעלות מספר הדרכות מועילות.