Unit Testing: אהבה ממבט ראשון

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

cc-by Toms Bauģis. flickr

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

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

שנייה… להתאהב?! שלווה? נירוונה? – “על מה אתה מדבר?”

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

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

מה אני אגיד? פלסיבו. האם לוקחים מחולה פלסיבו שיש לו השפעה?

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

מינוח: “קוד פעיל” = productive code. זה שעושה את העבודה.
בדיקות יחידה הן:

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

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

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

  • נכתבות ע”י אנשי QA, מפתחים צעירים או סטודנטים.
  • כלי יעיל לשיפור איכות חיצונית.
  • נזרקות לאחר שהקוד הפעיל “משוחרר” (shipped).
  • קוד שקל במיוחד לכתיבה.
  • מיוצרות ע”י כלים אוטומטיים (generated). יש להפעיל לא-מעט חשיבה אנושית בריאה על מנת לכתוב בדיקות יחידה טובות.
  • בדיקות אינטגרציה / מערכת / רכיב  component test / פונציונליות functional test / או API test.

בדיקות אינטגרציה / מערכת / פונציונליות / … (מסומנות בתרשים למטעה כ”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. עשה ג’

במקרים אלו קוד הבדיקה יכלול כנראה mock על מנת להקשיב להתנהגות הקוד והבדיקה תבדוק שא’, ב’ וג’ אכן נקראו. אולי אפילו שהם נקראו לפי הסדר. קוד הבדיקה עלול להיות ארוך משמעותית מהקוד הפעיל. אם הפעולות המדוברות שייכות לאובייקטים אחרים – אדרבא. לעתים קרובות קוד האינטגרציה יכלול אפילו קריאות למערכות אחרות / קוד שלא באחריותנו. עלינו לכתוב Mock Object ועוד Mock Object… בשביל מה כל זה? בשביל לבדוק לוגיקה דיי פשוטה של קריאה לסט פעולות ע”פ הסדר?

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

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

קוד לוגי (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.

בכתיבת קוד בדיקות בג’אווהסקריפט מקובל לכתוב את בדיקת-היחידה בקובץ html נפרד. ניתן לכתוב קוד שיפעיל פעולת submit ויתפוס את ה error שנזרק. התוצאה: אנו כותבים ומשקיעים יותר שורות קוד וזמן בבדיקה מאשר בקוד הפעיל. לא סימן טוב.
במקרים אחרים, פחות ידידותיים (למשל אסינכרוניות, הסתמכות על סביבה חיצונית כמו טעינת image), כתיבת הבדיקות עלולה להיות פרויקט של ממש. אנו רוצים להימנע מכך.

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

הנה הקוד לאחר שעשינו לו 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 גבוה מהיעד – זה לא בהכרח סימן טוב. סיכוי טוב שאנשים משקיעים בבדיקות יותר ממה שמשתלם.
  • למרות שבתאוריה ב TDD אמור להיות 100% CC, תאוריה זו תיאוריה: לא כל הקוד נבדק. אולי אפשר לצפות ל CC קצת יותר גבוה – אך לא בהרבה.

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

(TDD (Test Driven Development

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

ראיתי מספר פרשנויות מוזרות שמתהדרות בשם “TDD”. למשל: צוות שכל תחילת ספרינט השקיע 2-3 ימים בכתיבת מסמכי בדיקה מפורטים בוורד, כתב את הקוד ואז בסוף הספרינט מימש את הבדיקות בקוד, שבכלל היו בדיקות פונקציונליות / מערכת. אם אתם רוצים להתהדר ב TDD או אפילו ATTD (נשמע טוב!) – לכו על זה. שום חוק מדינה לא יאסור על מאלף-סוסים, נאמר, להתהדר בכך שהוא “עובד TDD”.

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

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

כלומר: קודם כותבים את קוד הבדיקה, ורק לאחר מכן – את הקוד הפעיל.

TDD הוא הפעלה חוזרת של סדר הפעולות הבא:

  1. הבינו מה הפונקציונליות (קטנה) שאתם רוצים להוסיף למערכת.
  2. כתבו בדיקת-יחידה שבודקת את הפונקציונליות הזו, קצה-אל-קצה.
  3. הריצו את הבדיקה: עליה בהכרח להיכשל, מכיוון שהפונקציונליות לא כתובה עדיין![ד]
  4. כתבו פיסת קוד הפשוטה ביותר שאפשר שתעביר בדיקה בודדת[ה]. אם הריצה הצליחה המשיכו לחתיכה הבאה וכו’.
  5. לאחר שכל הבדיקות ירוקות (עברו בהצלחה) – המשיכו לפונקציונליות הבאה.

הסבבים ב TDD מאוד קצרים: כתיבה – הרצת בדיקות, כתיבה – הרצת בדיקות.

המתכנת מחליף תדיר 2 כובעים: כותב הקוד הפעיל וכותב הבדיקות, והוא אמור לנסות בכל כובע “להערים” על הטיפוס השני ולספק לו את המינימום האפשרי. כלומר: להערים על עצמו.

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

בפועל TDD מסייע:

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

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

סיכום 

כמה סימנים שיכולים להעיד שמשהו עם בדיקות-היחידה אצלכם לא בסדר:

  • הבדיקות נכשלות תדיר – גם כשהקוד הפעיל עובד בסדר => בדיקות רגישות לשינויים (fragile tests).
  • הבדיקות שלכם בודקות קוד שלא סביר שיישבר (למשל קוד מה JDK)
  • הבדיקות שלכם נכשלות בהמוניהן – כמו בדיקות פונקציונליות.
  • אתם עושים שימוש תדיר ורב ב Mock Objects (שהם בעצם סוג של patch לקוד קשה-לבדיקה).
  • יש לכם בדיקות שמשאירות “עקבות” לאחר שרצו. זו יכולה להיות בעיה או בבדיקות או בקוד הפעיל.
  • הבדיקות שלכם רצות לאט.

כמה מדדים לשימוש בריא בבדיקות-יחידה:

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

שיהיה בהצלחה/

—-

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

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

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

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

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

הפוסט פורסם במקור בבלוג Software Archiblogh

ליאור בר-און

ליאור בר-און הוא Chief Architect בחברת סטארטאפ ישראלית גדולה.

הגב

7 Comments on "Unit Testing: אהבה ממבט ראשון"

avatar
Photo and Image Files
 
 
 
Audio and Video Files
 
 
 
Other File Types
 
 
 
Sort by:   newest | oldest | most voted
פבל
Guest

אחלה טור, ליאור.
מה שבאמת היה חסר לי, ולרגע הרגשתי שאתה נוגע בו – ולא היא:
האם באמת TDD (כפי שמקובל בשפות כמו רובי למשל) מוביל לפיתוח זול יותר בסטארטאפים, שכל שניה משנים את הדרישות ואת הקוד?
הרי ההגיון הוא שזמן הפיתוח יתארך פי 3-4 לפחות (שכן לפעמים יותר קשה לכתוב את הבדיקה מאשר את הפונקציה)
האם בreal world scenario לא כדאי לחכות חודשיים-שלושה כדי לקבל פידבק משתמשים, שאכן הפונקציה רצויה ואהובה לפני שמשקיעים בבניית בדיקה?
ואולי עדיף בלי בדיקות בכלל, לתת לצוות QA ידני לבדוק.

ליאור בר-און
Guest
היי פבל, תודה על התגובה. אם יצרתי רושם שגוי – אני רוצה לתקן: שימוש בבדיקות יחידה לא אמור להוסיף הרבה לזמן הפיתוח. הזמן הנוסף שמושקע בבדיקות עצמן מוחזר בכך שניתן לבדוק את הקוד ולסמוך על הבדיקה בתוך ה IDE – לא צריך לדפלא (deploy) את הקוד עבור בדיקה שהקוד עובד. המקרה בו ציינתי שלקח לנו פי 3 זמן לכתוב בדיקות מהקוד הפעיל, היה מצב קיצוני שניסינו לבדוק 100% משורות הקוד הפעיל, קוד שכלל פעולות IO / רשת. לדוגמה – הקוד שמטפל ב connection timeout – אז יצרנו מצב שמשחזר timeout תוך פחות משנייה. בנוסף: לאף אחד מאיתנו לא היה ניסיון… Read more »
פבל
Guest

ליאור, אתה מחמיץ את הנקודה.
לכתוב unitest, זה לכתוב אפליקציה נוספת. לעיתים, כאשר מדובר על gui מסובך, כאשר לוחצים על כפתורים בפריים אחד ומצפים לקבל תוצאה מגוונת בפריים אחר, הקידוד יכול להיות מסובך עד כדי יותר מפי 4 זמן (תלוי בcoverage)
להגיד שהזמן לא אמור להתארך, זה לא רציני.

מארק צוקרברג כתב את פייסבוק 1.0 ב22 יום ללא unitests. מיראביליס כתבו את ICQ ללא unitest. שני אלו צברו נפח משתמשים והגיעו רחוק.
אם הם היו משקיעים זמן בunitest זמן הפיתוח היה מתארך פי 3 ובזמן הזה היו יכולים להכנס מתחרים שהיו מוציאים אותם מהמשחק.

זה העניין שהרגשתי שלא התייחסת אליו בכתבה, וחבל.

ליאור בר-און
Guest
היי פבל, אם אתה בודק לחיצה של כפתור על המסך – אני יכול להבין איך ההשקעה בבדיקה יהיה פי 3 מזמן הפיתוח. אבל, בדיוק מה שניסיתי להראות בפוסט (אם תתבונן שוב על דוגמת הקוד – קראת את כל הפוסט?) הוא כיצד אני בודק *רק* את הקוד הלוגי בו העלות-תועלת של הבדיקות היא הגבוהה ביותר ומוותר על החלקים שלא-משתלמים. מישהו מנוסה, שמתמקד בעלות-תועלת בבדיקות היחידה שלו (כלומר, לא בודק “הכל” בלי הבחנה) יכול להגיע לפריון דומה למישהו שלא כותב בכלל. חוויתי זאת בעצמי. אם מארק צוקרברג היה משקיע 23 ימים והיו לו גם בדיקות-יחידה, הוא היה יכול להתקדם לשלבים הבאים ביתר… Read more »
גל
Guest

שונא TDD, תמיד שנאתי וזה לא ישתנה. מבחינתי זה פשוט בזבוז זמן.

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

לדעתי מי שטוען שלפתח עם TDD לא לוקח משמעותית יותר זמן מלפתח ללא TDD כנראה לא מתכנת מספיק מהר…

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

ליאור בר-און
Guest

היי גל,

אני מזדהה עם הרגשת הסבל. גם לי היו ימים קשים מאוד עם TDD (הניסיון להגיע ל100%)

האם אתה יכול לאפיין “חלקים קריטיים בקוד” שכן משתלם לבדוק אותם?
האם יכול להיות שזהו כל הקוד הלוגי (if/for) שאותו *מאוד קל* לבדוק?

התבונן על הפסקה (החשובה!) “מה בודקים בבדיקות-יחידה?”.
נדמה לי שאנחנו מדברים בדיוק על אותו הדבר.

ליאור

שרון ויינטה
Guest
מקרה קלאסי של ביצה ותרנגולת. כשאת/ה ממהר לבנות מערכת (ראה ערך סטארטאפ) אז אין לך זמן לכתוב קוד בדיקה ואתה סומך על הQA שפועלים “במקביל” אליך. כאשר בסיס הקוד גדל ולא רגילים לכתוב בדיקות אז מרגישים שמאוחר מדי וגם אין זמן כי כבר צריך להוציא את גירסה 2 או 3 שגם ככה מאחרות…הבעייה היא שכל באג בשלב זה נתפס בשלבים מאוחרים, לעיתים אצל הלקוח והזמן שלוקח למצוא אותו הוא ארוך פי כמה. כשבונים מערכת גדולה ורצינית להקדיש זמן מינימלי לכתיבת בדיקות למודולים הבעיתיים ביותר, אם זה הלוגיקה או אם זה המקומות העדינים ביותר, בעיקר בשכבות הנמוכות ביותר. כשמתחילים גרסה חדשה… Read more »
wpDiscuz

תגיות לכתבה: