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

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

1. מיקוד הוא הכל

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

אבל אלו אינן בדיקות יחידה.

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

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

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

2. עדיף למחוק בדיקת יחידה מלהשאיר דילוגים

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

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

כמובן שאף פעם לא תגיעו לתקן את הבדיקות המדולגות והדיווח עליהן ימשיך להופיע ולדכא אתכם עד עולם.

הערך של בדיקות מגיע מזה שאנחנו יכולים לראות תוך 2-3 שניות שכולן עברו. כל תוצאה שונה מהכל עבר צריכה להדאיג. בהקשר הזה אף פעם אל תשארו עם בדיקות שנכשלות או אפילו בדיקות שנכשלות מדי פעם. הצפיה בתוצאת הרצת בדיקות צריכה להיות פעולה אוטומטית. הכל עבר? ממשיכים. לא הכל עבר? מתחילים לבדוק מה הבעיה.

3. הזהרו מבדיקות מתוחכמות

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

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

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

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

4. גם לבדיקות יחידה יש תאריך פג-תוקף

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

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

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

5. הערך האמיתי של בדיקות

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

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

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

6. ובונוס לסיום

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