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

מי שניסה Unit Tests מוצלח עלול פשוט להתאהב! כנראה שמעבר לתמורה המעשית – זוהי חוויה רגשית. אחרת, אינני יודע להסביר מדוע אנשי מפתח בעולם התוכנה מתאמצים להוכיח שכתיבת Unit Tests בעצם חוסכת בעלויות הפיתוח[א], מעלה את האיכות, משמחת את הלקוח ומרצה את בעלי המניות… . נראה שהם מאמינים מושבעים המנסים רק להוכיח את אמונתם. מי שחווה את הנירוונה של הרצה של 100+ בדיקות שמסתיימות כולן בהצלחה אחרי ביצוע שינוי מהותי בקוד – מבין את ההרגשה הממכרת. הצבע הירוק זורם ומפיח חיים בעץ הבדיקות שלכם. החרדה מהלא-ברור מתחלפת בשלווה מרגיעה שזורמת בעורקיכם ומפיגה כל זכר לקושי או מתח…

שנייה… להתאהב?! שלווה? נירוונה? – “על מה אתה מדבר?!”
אני יכול להעלות בזיכרוני תמונות של עשרות פרצופים סובלים וממורמרים בעקבות “איזו החלטת הנהלה לכתוב Unit Tests”. אז תנו לי להסביר: פעמים רבות ראיתי ניסיונות לאימוץ Unit Tests שגרמו סבל רב למפתחים ו/או לא החזיקו מעמד זמן רב. הייתי אומר שנתקלתי ב 2-3 ניסיונות כושלים לאמץ Unit Tests על כל ניסיון מוצלח.

יש עוד זן של אימוץ Unit Tests שאינני יודע אם להגדיר כהצלחה או כישלון. אקרא לזן זה “מטופש, אבל אופטימי”. מדובר בקבוצת מפתחים שמשקיעים המון זמן בכתיבת בדיקות-יחידה מסורבלות וכמעט חסרות משמעות – אך הם מרוצים. המורל גבוה והצוות מעיד על עצמו “מאז שהתחלנו לכתוב בדיקות האיכות נסקה וקצב הפיתוח הואץ. זה עובדדדדדד!”.
מה אני אגיד? פלסיבו. האם לוקחים מחולה פלסיבו שיש לו השפעה?!

מה הן בעצם בדיקות-יחידה (Unit Tests)?

בדיקות יחידה הן:

• מקבילות לקוד הפעיל. לכל חתיכת קוד פעיל יש חתיכה “חברה” של קוד בדיקה שבודק אותו.
• נכתבת ע”י המפתח שכתב גם את הקוד הפעיל.
• רצות כל הזמן, תוך כדי פיתוח, כמו “קומפיילר שני”.
• בהערכה גסה, ניתן לצפות לשורת קוד של בדיקות לכל שורת קוד של קוד פעיל.
• דורשות תחזוקה. ימצאו בהן באגים.
• דורשות שהקוד הפעיל ייכתב בגישה קצת אחרת: “Testable Code”.
• רצות מהר. ממש מהר[ב].
• דורשות מאסה קריטית (של כיסוי הקוד הפעיל, לפחות באזור מסוים) – על מנת להיות יעילות.
• “בונות” אצל המפתחים ביטחון אמיתי בנכונותו של הקוד הפעיל.
• משפרות איכות פנימית.
• מובילות אותנו לכתוב קוד מודולרי וברור יותר. בזמן כתיבת הבדיקה, אנו הופכים לרגע מ”יצרני הקוד הפעיל” ל”צרכני הקוד הפעיל” – מה שעוזר מאוד להבחין בקלות השימוש בממשקים / API.
• משרתות אותנו כתיעוד מעודכן ורב-עצמה.

ההבדל בין בדיקות יחידה שמחזיקות את ההשקעה לבין אלו שלא. שימו לב: לעתים נרצה בדיקות יחידה גם אם הן עולות לנו יותר. מקור:  http://xunitpatterns.com/Goals%20of%20Test%20Automation.html

בדיקות אינטגרציה / מערכת / פונציונליות / … (מסומנות בתרשים למטעה כ”F”) בודקות את המערכת כמקשה אחת. הן לרוב מתבצעות מול השכבות העליונות של המערכת (כדי לחסוך עבודה) ומפעילות פונקציות שקריאה להן מחלחלת לשאר המערכת.
כאשר יש באג באחד הרכיבים במערכת – בדיקות רבות יכשלו. כל הבדיקות שעשו שימוש באותו הרכיב. אם נרצה לפתור את הבאג יהיה עלינו להתחיל ולחקור מהיכן הוא נובע. רשימת הבדיקות שנכשלו ייתנו לנו רק כיוון כללי לחקירה.

בדיקות יחידה, לעומת זאת, בודקות יחידות בודדות באופן בלתי-תלוי. הן בודקות הן את השכבות העליונות והן את השכבות הנמוכות. לכל מחלקה יש בד”כ מספר בדיקות (מתודות-בדיקרה. מסומנות בתרשים למטה כ “U”). כאשר בדיקת-יחידה נופלת ברור מאוד היכן התקלה. על מנת למצוא את שורת הקוד המדוייקת בה קרתה התקלה, נריץ debugger על הבדיקה בספציפית שנכשלה. לעתים – יהיה מספיק לראות לבחון את הרשימה המצומצמת של הבדיקות שנכשלו על מנת לקשר ולהבין איזו שורה אחראית לתקלה.

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

האם בדיקות היחידה שלכם מתנהגות יותר כמו בדיקות פונקציונליות? – סימן שיש לכם בדיקות פונקציונליות ולא בדיקות יחידה. עצם זה שאתם משתמשים ב qUnit / nUnit / jUnit לא אומר שהבדיקות שנכתבות הן אכן בדיקות יחידה!

הערה: איני מנסה לטעון ש”בדיקות-יחידה הן טובות” או “בדיקות פונקציונליות הן פחות טובות”. פתרון אוטומציה מאוזן כולל לרוב כ 70% בדיקות יחידה, כ 20% בדיקות פונקציונליות וכ 10% בדיקות ל UI. הבדיקות השונות משלימות זו את זו.

מה בודקים בבדיקות יחידה?

אפשר לחלק את הקוד הפעיל ל3 אזורים:

קוד “נטול לוגיקה”
לדוגמה: getters או setters (שלא משנים את הערך), כתיבה ללוגים או השמות של ערכים מאובייקט אחד לאובייקט שני.
הסיכוי שקוד שכזה ישונה ויישבר במהלך חיי המוצר הוא לא גבוה. יתרה מכך: דמיינו כיצד תראה בדיקה של קוד שכזה:

1. קבע את X להיות 4.
2. השם את X.
3. קרא את X והשווה שהוא 4.

קוד הבדיקה הוא בעצם השתקפות של הקוד הפעיל. אם קראנו את הקוד הפעיל והוא נראה לנו תקין – לא סביר שקריאה בקוד הבדיקה תגלה לנו תובנה חדשה. גרוע מכך: סביר שהבסיס לקוד הבדיקה הוא בעצם copy-paste של הקוד הפעיל.
מסקנה: התמורה להשקעה בבדיקות קוד “נטול לוגיקה” היא קטנה ביותר ומומלץ לא לבדוק סוג כזה של קוד.

קוד אינטגרציה
קוד זה הוא קוד Gluing שמחבר בין רכיבים / מערכות:

1. עשה א’
2. עשה ב’
3. עשה ג’

קוד לוגי (Business Logic)
קוד זה מתאפיין באזורי קוד שהם מופיעות פקודות if ו for (או המקבילות בשפה בהם אתם עובדים) – conditional logic. הקוד לוגי הוא הקוד הרגיש ביותר ל”שבירה”. בעצם: לעתים רבות הוא לא כתוב כשורה מלכתחילה!

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

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

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

function FormValidator($form) {

  var username = $form.find('#username'),
      email    = $form.find('#email'),
      error    = $form.find('.error');



  $form.bind('submit', function() {


    if (username.val() === 'Wizard') {
      error.html('Your argument is invalid');
      return false; // prevents the submission of the form
    }
    else if (username.val() !== 'Harry') {
      error.html('Your name is invalid');
      return false;
    }
    else if (!/@/.test(email.val())) {
      error.html('Your email is invalid');
      return false;
    }


  });
};

בפונקציה ניתן לזהות מספר רב של משפטי if, מה שמעיד על כך שיש כאן קוד לוגי – קוד שאנו רוצים לבדוק. גם regular expression (שהתחביר שלו בג’אווהסקריפט הוא טקסט בין סוגרי “/” כמו בביטוי האחרון) הוא קוד לוגי. ביטוי ה regex מבטא תיאור conditional logic כללית שנוכל להזין לה כמה דוגמאות ולוודא שהתוצאה המתקבלת היא הרצויה.

כדי להפעיל את הפונקציה אנו זקוקים להעביר ארגומנט בשם form$ (אובייקט jQuery) שנוצר ממציאת אלמנט form ב HTML שמכיל תגיות (כנראה מסוג input) עם מזהים בשם username וemail. את התוצאה של הרצת הפונקציה נוכל לקרוא מתוך שדה ה error (כמה נוח) בתוך אלמנט ה form.

יש לנו כמה בעיות:

• הפונקציה החיצונית תרוץ, אך הפונקציות הפנימיות לא יפעלו ללא לחיצה של המשתמש על כפתור “Submit”. אולי אפשר “לזייף” לחיצה ב javaScript?
• ה errors הם text string למשתמש שיכולים להשתנות בקלות. כל שינוי ישבור את הבדיקה => בדיקה רגישה לשינויים.
• טעינת ה html markup (דף HTML עם javaScript נלווים) עלולה לקחת זמן רב. כלל שהבדיקה אטית יותר – יריצו אותה פחות. בבדיקות JavaScript מקובל להפריד את הבדיקות לקובצי html נפרדים ולהריץ רק אותם – אך עדיין יש פה עבודה לכתוב ולתחזק את ה makrup.

הנה הקוד לאחר שעשינו לו refactoring ובודדנו את הקוד הלוגי – ללא תלות ב DOM:

FormValidator.validate = function(username, email) {

  var errors = [];

  if (username === 'Wizard')
    errors.push('Your argument is invalid');

  else if (username !== 'Harry')
    errors.push('Your name is invalid');

  else if (!/@/.test(email))
    errors.push('Your email is invalid');

  return errors;

}

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

• החזרת רק קוד ה error והפיכתו לטקסט מאוחר יותר.
• קבלת כל אלמנטי ה input בטופס כמערך בתור פרמטר לפונקציה – כך שלא יהיה צריך לשנות את החתימה שלה (ושל הבדיקות) בכל פעם שנוסף לטופס פרמטר.

כלי עבודה

• xUnit – ספרית בדיקה לשפה שלכם כגון nUnit ל #C או jUnit לג’אווה.
• (CI (continuous integration על מנת להריץ את הבדיקות כל הזמן ולדעת מוקדם ככל האפשר – כשמשהו נשבר.
• Code Coverage Tool – על מנת לדעת כמה מהקוד שלכם עובר בדיקה. למשל Emma ל Java או NCover ל #C.

אם אתם עובדים עם Java ו Jenkins (כלי CI) יש תוספת מאוד נחמדה בשם Sonar שעושה גם Code Coverage בעזרת Emma ומאפשרת ביצוע Drill Down שימושי למדי.

על מדד ה Code Coverage
אחד הדברים שמנהלים אוהבים לעשות הוא להציב לצוות יעדים מספריים. (Code Coverage (CC הוא מדד מספרי ברור וגלוי (אם הוא משתקף באיזה דו”ח שקל להגיע אליו) המתאר את כמות הקוד הפעיל שמכוסה ע”י בדיקות-היחידה. החישוב הוא % שורות הקוד הפעיל שהופעלו בעת הרצת כל בדיקות היחידה הקיימות אצלנו.

בעבר פיתחתי רגשות שליליים עזים למדד ה Code Coverage. הייתי חבר בפרוייקט בו נדרשנו ל 100% כיסוי – לא פחות. המערכת הייתה מערכת P2P Video Streaming שהייתה כתובה חציה ב Java/AspectJ וחצייה ב ++C. בקוד היו חלקים גדולים שהתנהגו בצורה סינכרונית, והיו פנייות רבות לפעולות I/O (לרשת). על מנת לבדוק חלקים מסויימים בקוד נאלצנו לכתוב את הבדיקות עצמן בצורה אסינכרונית: השתמשנו בספריית ה Concurrency של Doug Lea בעיקר עבור קוד הבדיקות – ורק מעט עבור הקוד הפעיל. זה היה בשנת 2003 ומקורות הידע בבדיקות-היחידה היה מצומצם.

הקזנו נהרות של דם בכדי להעלות למעל 90% CC. הכי גבוה שהגענו היה 93%-לרגע, כך נדמה לי.
תכונה בולטת של CC הוא המאמץ השולי הגובר: להשיג 50% זה יחסית קל. כל אחוז מעל 80% הוא עבודה מתישה וקשה – ובכל רגע נתון מישהו יכול לבצע submit של קוד לא-בדוק ו”לזרוק” את הצוות אחוז או שניים אחורה.
על האחוזים מעל 90% אין לי מה לדבר. זה נראה כמו טעות חישוב – כי לא נראה היה שאפשר באמת להגיע לשם. הוספנו לקוד הפעיל getters[ג] רק כדי “לסחוט” עוד קוד קל-לבדיקה ולשפר אחוזים. הערכנו שאנו משקיעים פי 3 זמן על קוד בדיקות מאשר על קוד פעיל (מצב לא בריא בעליל, אני יודע כיום לומר). מאז ראיתי פרוייקט שבו השקיעו כשליש מהזמן על כתיבת בדיקות, והחזיקו ב CC של כ 80% באופן שוטף.

כמה מסקנות:

• התמודדות לא מוצלחת בכתיבת בדיקות-יחידה עלולה לגרום למפח נפש רציני.
• היעד הסביר, לדעתי כיום, ל CC תלוי מאוד בסוג המערכת:
  בקוד שרובו אינטגרציה / UI / IO אני חושב שבריא לשאוף ל 60-70% CC.
  בקוד שרובו parsing או לוגיקה טהורה (לדוגמה XML Parser) אפשר בהחלט לשאוף ל 80-90%.
  במערכת שהיא באמצע (כמו רוב המערכות) אני חושב שיעד בריא הוא 70-80% CC. אני מציין טווח ולא מספר מדויק כי CC הוא מדד “חי”. בכל Submit של קוד הוא ישתנה. להישאר כל הזמן בטווח של 10% – הוא משהו שאפשר לדרוש מצוות. במיוחד במערכת גדולה.
• CC הוא תנאי מחייב אך לא מספק. אם יש לכם 20% CC – בטוח שהקוד שלכם לא בדוק טוב. אם יש 80% CC – אזי זה סימן טוב אבל יש לעבור על הבדיקות ולוודא שהן משמעותיות. ניתן בקלות להשיג CC גבוה עם בדיקות חלקיות ולא יעילות.
• למרות שבתאוריה ב TDD אמור להיות 100% CC, תאוריה זו תיאוריה: כמעט תמיד יהיו חלקים של חוק אינטגרציה, Adapters למשל, שלא נכון או כדאי לבדוק אותם.

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

(TDD (Test Driven Development
TDD הוא סוג של “השלב הבא” בבדיקות-יחידה. הרעיון הוצג ע”י קנט בק – גורו וחדשן אמיתי בעולם התוכנה.

TDD היא טכניקה שנוצרה על מנת לכתוב בדיקות-יחידה טובות יותר, אך היא גדלה והפכה להיות “דרך חיים”.
הנה כמה רעיונות:

• איך אתם יודעים שתצליחו לכתוב קוד בדיק (testable) ולא תאלצו לעשות בו שינויים אח”כ? – פשוט כתבו כל בדיקה בסמיכות רבה לקוד שהיא בודקת. אולי אפילו כיתבו את הבדיקה לפני.
• איך תוודאו שהכיסוי שלכם של בדיקות הוא אופטימלי? – החליטו שקוד פעיל נכתב רק על מנת לגרום לבדיקה לרוץ בהצלחה. “מה שלא בדוק – לא קיים“.
• איך תפחיתו באגים בבדיקות שלכם – ופרט את המקרים של בדיקות שעוברות בהצלחה גם כאשר הקוד לא עובד כשורה? כתבו והריצו את הבדיקות קודם לכתיבת הקוד וודאו שהן נכשלות.

• להתמקד במטרה ולכתוב רק קוד שנדרש (“eliminate waste”)
• להשיג בדרך הקצרה והפשוטה קוד בדוק עם Code Coverage גבוה.
• לכתוב את ה API / interface של כל מחלקה בראייה של הלקוח (= הבדיקה) – דבר שמסייע ליצירת API טובים וברורים.
• מכריח אתכם לכתוב קוד מודולרי ובדיק (testable).

שיהיה בהצלחה!

—-

[א] ע”פ התאוריה האקדמית, השקעה באיכות לרוב מעלה את עלויות הייצור – לא מוזילה אותן.

[ב] כאשר בדיקות יחידה מתחילות לרוץ לאט (נאמר, כפול מהקומפיילר או יותר) מחלקים אותן ל 2 חבילות: “בדיקות מהירות” שרצות כל הזמן, ו”בדיקות אטיות” שמריצים מדי פעם כמו ב CI או לפני פעולת submit של קוד.

[ג] שלפנים – בעברית. כמובן.

[ד] בלימוד TDD מלמדים לצפות לכישלון “אין כזו מחלקה”, אח”כ “אין כזו מתודה” ואח”כ – ערך לא נכון. ממש להתקדם בנאיביות. כשעובדים בפועל – מדלגים כמובן על השלבים הברורים-מאליהם.

[ה] בלימוד TDD מלמדים שאם אתם בודקים את הפונקציה (add(a,b והבדיקה הראשונה בודקת ש 2+2=4 – יהיה נכון לכתוב את גוף הפונקציה בצורה הכי מוכוונת-מטרה שאפשר, כלומר return 4. זאת על מנת לוודא שאינכם כותבים קוד מיותר (“מה שלא בדוק לא קיים”) אך גם להרגיל אתכם לכתוב בדיקות מספיק מקיפות שבודקות את הפונקציה במספר מספיק של מקרים.