שאלה חשובה לכל הצוותים היא מה כדאי לבדוק, ולא מה היא בדיקה. בדיקה היא אמצעי להשיג את המטרה, ותהליך הבחירה בקביעת סדר העדיפויות של הבדיקה של חלקים שונים ב-codebase יכול להיות קשה.
הדרך הטובה ביותר לתת עדיפות היא על סמך בסיס הקוד ויעדי הצוות שלכם, אבל חשוב לזכור שלמרות שנדרש מעט זמן ורוחב פס כדי לכתוב הרבה בדיקות קטנות (בחלק התחתון של פירמידת הבדיקות, כמו בדיקות יחידה) שיש בהן כיסוי רב של הקוד, הן לא בהכרח מפחיתות את הסיכון הכולל לפרויקט שלכם.
כדי לבחור מה לבדוק קודם, לחשוב על תרחישי השימוש העיקריים באפליקציה, באתר או בספרייה. אפשר לעשות זאת על ידי כתיבת בדיקות של רכיבים לגבי חלקים קריטיים של האתר, הרכיבים העיקריים שעליהם הוא מבוסס על חוויית המשתמש. לדוגמה, מפתחים של אתר שמאפשר למשתמשים להעלות ולנהל נתונים של זמני זמנים צריכים לדמיין ולבדוק את הדרכים השונות שבהן משתמשים יכולים לבצע את המשימות האלה.
גישה נוספת לתעדוף היא השגת כמות המידע הגדולה ביותר. אם יש לכם חלק "מסוכן", מדור קודם או כתוב בצורה שגויה ב-codebase, שאף אחד בצוות שלכם לא אוהב לעבוד עליו, כדאי ליצור סביבו בדיקות כדי להפוך את ההתנהגות שלו לעקבית יותר לפני שתתעלמו ממנו, או שתבדקו מחדש את הכלי כדי לפתור את הבעיה. אפשר לחשוב על זה כמו על פיגועים ובניית בניין שכבר קיבל גינוי, אבל מרכז הנתונים שלכם עדיין מתארח בו.
ממדי
הוספנו את הרעיון של פירמידה לבדיקה, או צורת בדיקה אחרת, אבל בדרך כלל יש מימד אחד בלבד של בדיקה: קו שמתחיל מהיקף קטן, בדיקות יחידה פשוטות ועד בדיקות מורכבות נרחבות - בדיקות יחידה מול בדיקות שילוב לעומת בדיקות מקצה לקצה.
עם זאת, חלק מהרשימה הארוכה של סוגי הבדיקות האפשריים לא מייצגות את רמת המורכבות, אלא מייצגות יעדים או טכניקות בדיקה. לדוגמה, בדיקות עשן הן קטגוריה אחרת של בדיקות שיכולות להיות בדיקות יחידה, מקצה לקצה או בדיקות אחרות, אבל המטרה היא לתת לבודקים בטוחים שהפרויקט הנבדק במצב תקין. ניתן להשתמש בבדיקות חזותיות גם על רכיב קטן או על האתר כולו.
ל-codebase יהיו דרישות ייחודיות. לדוגמה, יכול להיות שב-codebase יש חשיבות רבה יותר להתאמה לתכונה אחת, ולכתוב סוגים שונים של בדיקות כדי לוודא שהוא פועל כמו שצריך. רק לעיתים נדירות, תכונה חדשה שזקוקה לבדיקה היא רכיב, פונקציה או גישה בודדים, ויכול להיות שההשפעה שלה על הפרויקט תופץ בתפוצה רחבה ובקנה מידה שונה.
ייתכן שגם סדר העדיפויות לבדיקות יהיה תלוי בצרכים העסקיים שלכם. מערכות טכניות מאוד עשויות לדרוש בדיקות יחידות מורכבות כדי לוודא שאלגוריתם ייחודי פועל כמו שצריך, ואילו כלים אינטראקטיביים מאוד עשויים להתמקד בבדיקות חזותיות או בבדיקות מקצה לקצה כדי לוודא שקלט מגע מורכבות מפיק את התגובה הנכונה.
הגישה שלך לבדיקה
נסו להתמקד בבדיקת התרחישים לדוגמה של ה-codebase, בלי קשר להיקף שלהם. דמיינו איך המשתמש עשוי להשתמש בחלק כלשהו בפרויקט – הוא יכול לייצג רכיב יחיד, פונקציה ברמה נמוכה יותר או תרחיש לדוגמה ברמה גבוהה. (הדבר עלול גם לחשוף ליקויים בתקצירים שלכם בכל קנה מידה, אם תגלו שהבדיקה לא מצליחה לבצע שום פעולה עם הקוד בבדיקה).
חשוב שלכל מקרה בדיקה יהיה יעד מוגדר בבירור. בדיקות "catch-all" גדולות יכולות להיות מסורבלות, בדיוק כמו בקוד שאינו בדיקה.
יתרון נוסף על פיתוח מבוסס-בדיקות
פיתוח מבוסס-מבחנים (TDD) הוא גישה ייחודית לבדיקה – אורתוגונלית בקנה מידה או לסוגים – מאחר שהיא כוללת כתיבת בדיקות שמיועדות להיכשל, לפחות בהתחלה. זה יכול לקרות גם בבדיקות ידניות וגם בבדיקות אוטומטיות: מתארים את היעדים שרוצים להשיג, בודקים מה חסר בפתרון או בקוד הנוכחי ומשתמשים בבדיקת הכשל כקו מנחה לקראת פתרון.
כמובן שלא כדאי לבדוק כל תרחיש אפשרי באפליקציה או ברכיב היפותטיים עוד לפני שמתחילים ליצור אותם. ל-TDD יש תפקיד משלו, וזה יכול להיות שימושי ככל ש-codebase נהיה מורכב יותר.
TDD הוא שיטה מומלצת גם לתיקון באגים. אם אתם יכולים לקודד את בקשת השחזור של באג, תוכלו להעביר אותו לבדיקה אוטומטית שתיכשל בהתחלה. אחרי תיקון הבאג, הבדיקה תעבור בהצלחה ותוכלו לקבוע אם התיקון הצליח ללא אישור ידני.
תיבה אטומה לעומת תיבה שקופה
הכוונה היא לאופן שבו אתם בודקים כל חלק של המערכת שלכם. במקרה שהוא אטום, אי אפשר לראות אותו מבפנים, לדוגמה, כשמשתמשים בממשק הציבורי של הכיתה במקום לבדוק את החלקים הפנימיים שלו.
עדיף להתחיל עם בדיקה של קופסאות אטומות, אלא אם יש סיבה ספציפית שלא לעשות זאת, כדי לתכנן בדיקות בהתאם לאופן השימוש ברכיבים שלכם, ולא תסיח את הדעת לגבי אופן הפעולה של הרכיבים הפנימיים. אם אתם מסתמכים רק על הממשק 'ציבורי' של נתיב הקוד (ולא בהכרח ציבורי למשתמשים שלכם, אבל אולי חלקים אחרים של הקוד), אתם יכולים להגדיר מחדש את הקוד ולשפר אותו, מתוך ידיעה שהבדיקה תזהה שינויים כלשהם.
דרך אחת להמיר את קוד ה-clear Box כך שיהיה אטום יותר, היא להציג רכיבים ניתנים להגדרה כמו הפשטות ליחסי התלות של הקוד, או התקשרות חזרה כדי לצפות במצב, במקום שהמצב הזה יהיה מקושר היטב למערכות אחרות. כך הקוד מופרד יותר ומאפשר לכם לספק גרסאות 'בדיקה'. אפשר גם לדמות איך הקוד מתקשר עם מערכות אחרות.