על בדיקות-יחידה (Unit Testing)

עודכן ב1/9 21:30

מי לא מכיר 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

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

ראיתי שני אנשים שישבו ביחד וכתבו אלגוריתם אך הסתבכו: כל רגע מקרה אחר לא עבד. הנטייה הייתה לא לכתוב קוד בדיקות עד שהאלגוריתם לא עובד, "למה לכתוב פעמיים?". דווקא בכך שהתחילו לכתוב בדיקות תהליך הכתיבה הסתיים מהר יותר: אדם אחד שכתב בדיקות הצליח לסיים את המשימה מהר יותר מאלו שלא. הכל בזכות faster feedback cycle.

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

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

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

לאחר עשור, אני מסתכל על 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. זאת על מנת לוודא שאינכם כותבים קוד מיותר ("מה שלא בדוק לא קיים") אך גם להרגיל אתכם לכתוב בדיקות מספיק מקיפות שבודקות את הפונקציה במספר מספיק של מקרים.

ויזואליזציה בצד הדפדפן

אני זוכר קבוצה של מפתחים שעבדו על מערכת בקרה לשרתים שנכתבה ב ++C. הם היו מפתחים ותיקים ומקצועיים ונראה היה שהם מסתדרים ללא בעיה.
אלו היו הימים המוקדמים של ג'אווה / #C כטכנולוגיות צד שרת. אני זוכר את הדיון שהתרחש: הציעו לאנשי הצוות לעבור להשתמש ב #C - אבל הם לא האמינו שזה יועיל להם. "מה יש ב #C שאין ב ++C? ניקוי זיכרון אוטומטי? אנחנו עובדים עם AutoPointers ואין לנו בעיות. #C היא טכנולוגיה למפתחים מתחילים".
- "יש לנו את ACE (ספריית תקשורת), אין שום דבר דומה ב #C" (ספריית התקשורת הבסיסית של #C הייתה טובה מספיק)
- "#C קיימת רק 3 שנים, ניתן לה כמה שנים להתבגר" (הממ... יש בזה משהו...)
- "אם נצטרך יום אחד לעשות משהו מיוחד - ++C תאפשר הכל" (אין מניעה להשתמש ב ++C בתוך תוכנת #C)
- "אין לנו זמן ללמוד שפה חדשה, אנחנו עמוסים בעבודה"
וכו'

אחרי שנתיים בערך כתבו את מערכת הבקרה מחדש ב #C - וזו הייתה הצלחה גדולה. זו הייתה מערכת לדוגמה שבה שימוש ב ++C היה מיותר.
האם מישהו היה שוקל כיום לכתוב מערכת שכזו ++C? - כנראה שלא.


תהליך דומה מתרחש כיום בעולם ה Client-Side. אחד האתגרים העומדים בעת פיתוח אפליקציות HTML5, ומובייל בפרט, הוא ליצור ויזואליזציה מושכת: משהו נעים למראה, ו"מגניב". הכלים המוכרים הם כנראה CSS3 וג'אווהסקריפט. CSS3 הוא כלי רב-עצמה ומי שמתמחה בו יכול להגיע לתוצאות מרשימות.

ויזואליזציה של טופס, שכאשר מסיימים למלא אותו הוא מחליק לתוך מעטפה. ללא JavaScript! מקור

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

כתיבת ויזואליזציה ברמה גבוהה בעזרת CSS3 הוא תרגיל מאתגר המלמד הרבה על CSS3 ו HTML - אבל הוא קשה משמעותית יותר לתחזוקה מאשר שימוש בספרייה שהיא יותר "גבוהה". כנ"ל לגבי אלמנט ה cavnas של HTML5: בעזרת קוד JavaScript ניתן לצייר על ה canvas  ברמת הפיקסל[א], וכך ליצור כל סוג של ויזואליזציה, אבל קל להגיע מהר מאוד לעשרות או אפילו מאות של קוד ג'אווהסקריפט לא-קריא.


Browser-Side Visualization Technology Stack
ברצוני להציג בפניכם את ה "Stack" טכנולוגיות הוויזואליזציה של צד-הדפדפן. זו לא הרכב אפשרי יחידי, כמובן, אך זה הרכב של כלים מוצלחים ומשלימים שיכול לתמוך במשימות ויזואליזציה מורכבות. לא מדובר ב"טוב" או "רע", כי אם בבחירת הכלי הנכון למשימה.

שתי הטכנולוגיות העיקריות לוויזואליזציה ב HTML5 הן SVG ו Canvas ומעל כל אחת יש ספריות שמרחיבות ומעשירות אותה. CSS משמש בעיקר ל Styling, כלומר לקחת את הקיים ולהוסיף לו טאץ' עיצובי. כפי שראינו למעלה, ניתן ממש "לצייר" בעזרת CSS - אך זו אינה מטרתו העיקרית.
הערה: אני מתעלם בכוונה מ WebGL וכל הנושא של תלת-מימד. באופן אישי אני מוצא את תלת-המימד פחות חשוב מוויזואליזציה דו-מימדית ולכן פוסט זה יעסוק רק בה.


HTML
כוללת בעיקר מבנה וטקסט. יכולות הוויזואליזציה הן דיי מוגבלות:

• ניתן להשתמש בטבלאות לעימוד. ישנה תגית <hr> לקו הפרדה רוחבי.
• ניתן ליצור ציורי ASCII מרשימים (שימוש בטקסט).
• ישנן מספר תגיות שמשפיעות על עיצוב הטקסט כמו <h1>...<h6> או תוויות b/u/i.

ויזואליזציה מסוג זה היא מאוד ווינטג' - ומתאימה לשימושים... מאוד מסוימים.

תקן ה HTML5 Semantics מבקש להסיר מ HTML כל אלמנט של ויזואליזציה והפיכתו ל Data Only. לדוגמה:תג <b> לא אמור להשפיע על הטקסט אלא רק לסמן אותו ככזה. בקובץ ה CSS יוכלו לעצב את תג ה <b> כבולט.
בכדי לא לשבור (מיליוני) דפי HTML5 קיימים, נותרו על כנן רוב היכולות העיצוביות של דף ה HTML, אם כי ההמלצה היא להמעיט את השימוש בהן.

CSS3

ל CSS3 יש כמה יכולות ויזואליזציה מתקדמות:

Gradients & Borders
זה אולי האלמנט בעל השימוש הנפוץ ביותר בצמד HTML5+CSS3. היכולת לקחת כל אלמנט (לרוב זו תהיה תיבה פשוטה: Div או Span), לעטוף אותו במסגרת יפה ולתת לה רקע.

אפשרויות ליצור מסגרת מעוגלת בפינה השמאלית-העליונה. מקור: http://www.css3.info

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

צורות שנוצרו בעזרת משחק במסגרת של Div בעזרת CSS. מקור:  http://www.css3.info/preview/rounded-border/

הנה cheat sheet של רשימת צורות שונות והמימוש שלהם בעזרת CSS.

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

אופס! לא עובד ב IE ישן. מקור:  http://v2.desandro.com/articles/opera-logo-css/

יתרון ל CSS על פני תמונות (שהשימוש בהן היה נפוץ בעבר) הוא ש CSS הוא ציור וקטורי: תיאור של ציור, שברגע ההצגה הדפדפן יכול להשתמש ברזולוציה המלאה של המכשיר לצייר אותו. אם מנסים להציג תמונה ברזולוציה גבוהה יותר ממה שנוצרה - ייווצר עיוות של "פיקסליזציה"[א2].

CSS מספק גם:

• יכולות טרנספורמציה - היכולת לסובב (rotate) ולמתוח אלמנטים ב DOM.
• יכולות מעבר (transition) המאפשרת להפוך אלמנט ממצב א' למצב ב' - הנה דוגמה (בhover על העיפרון הוא ינוע לצד ימין). יכולות אלו מקבילות במידה רבה ל"אפקטים" של jQuery. ל jQuery יש היתרון של קביעת הפרמטרים בזמן הריצה (הרי את קובצי ה CSS יש לכתוב מראש) - כך שעדיין קל יותר להשתמש ב jQuery בדפים דינמיים.
• אנימציה, יכולת שדומה ליכולות מעבר, אך היא תכונה של האלמנט ולא אירוע חד-פעמי. הנה דוגמה לציור CSS עם אנימציה.

סה"כ CSS3 מציגה סט יפה של יכולות שיכול להספיק כדי לתת "טאץ של ויזואליזציה" בממשק "מבוסס-טופס". CSS הוא סטנדרטי ומוכר - מה שמבטיח מגוון רחב של כלים ודוגמאות באינטרנט.

אם אתם זקוקים ליכולות שמעבר לכך, אני ממליץ לכם להימנע מלהפוך ל"CSS Ninja" ופשוט להשתמש בכלי ויזואליזציה "כבדים יותר" עליהם נדבר בהמשך.

Canvas
אלמנט ה Canvas של HTML5 הוא כמו Div המכיל רשת של פיקסלים (bitmap) וניתן לצייר עליו בעזרת קוד javaScript. הנה דוגמה:

HTML:

<canvas id="myCanvas" width="120" height="120"></canvas>

JavaScript:

    function draw() {

      var canvas = document.getElementById("myCanvas");

      if (canvas.getContext) {

        var ctx = canvas.getContext("2d");

        ctx.fillStyle = "rgb(200,0,0)";

        ctx.fillRect (10, 10, 55, 50);

        ctx.fillStyle = "rgba(0, 0, 200, 0.5)";

        ctx.fillRect (30, 30, 55, 50);

      }

    }

תיצור את התוצאה הבאה:

הפעולות הזמינות על הקנבס הן פעולות ברמת הפשטה נמוכה ("low level") ומזכירות מאוד 2D API (כגון זה של ג'אווה):

• ציור צורות כגון קווים, מלבנים, עיגולים ונקודות כאשר אפשר לקבוע את צבע ועובי המסגרת ("Stroke") וצבע המילוי ("fill") - שיכול להיות גם gradient.
• הרכבת של צורות (compositing) - ציור של צורות אחת על השנייה עם הגדרות אפשריות שונות כיצד יתנהגו הפיקסלים החופפים לשתיהן: האם הם יהיו של צורה A של צורה B, או פונקציה לוגית אחרת. ראו תרשים למטה המתאר את אפשרויות ה composting. 
• טעינה של תמונה (קובץ PNG למשל) לתוך ה canvas בעזרת פקודת (drawImage (image,x,y
• בכל שלב ה canvas משמש כ bitmap עליה ניתן לעשות פעולות, כגון טרנספורמציות - סיבוב, שינוי קנה המידה או שמירה כקובץ jpg / png.
• אנימציה. ה canvas עצמו לא מספק יכולות אנימציה מפורשות, אולם בעזרת setInterval והרכבה (compositing) של שכבות canvas ניתן ליצור אנימציות מרשימות. SetInterval (סטנדרטי של JS) משמש על מנת לקרוא לפונקציית javaScript שתעדכן את ה Canvas כל פרק זמן. דרך אחת מקובלת היא לחזור על אותה פונקציית ציור על פעם עם ערכים אחרים (הזחה, סיבוב, צבעים שונים...). על מנת לא לצייר את כל המשטח מחדש בכל פעם ניתן להחזיק משטח "רקע" ומשטח "חזית", לבצע את השינויים במשטח החזית ולהרכיב אותו עם משטח הרקע.
  ל Canvas יש יכולת של שמירת מצב (פונקציות save ו restore) שמאפשרות לחזור לחזור למצב קודם של ה canvas. יכולת זו גם משמשת לעתים בבניית אנימציות.
  הנה דוגמה לאנימציית canvas טיפוסית. הנה הקוד הרלוונטי.

אפשרויות ההרכבה ב canvas בין source ל destination

בקישור זה תוכלו למצוא ריכוז ("Cheat Sheet") של היכולות העיקריות של ה Canvas.

לסיכום canvas הוא כלי רב-עצמה אך Low Level. כמות הקוד שיש לכתוב היא רבה, אם כי בניגוד ל"ציור" ב CSS שדורש הרבה יצירתיות והתחכמות - הציור ב canvas הוא פשוט וצפוי, תכונה שאני רואה בה יתרון ברור. הביצועים של canvas יכולים להיות טובים למדי - בסדרי גודל דומים לזו של אפליקציה שולחנית (לא עוד "ווב איטי"). כמובן שעל מנת להגיע לתוצאות כאלו כדאי לוודא שאתם מנצלים את האצת-החומרה האפשרית ומתייחסים לכללי בסיס של ביצועים ב canvas.


(SVG (Scalable Vector Graphics
SVG איננה טכנולוגיה חדשה. היא קיימת כעשור, החל מ 1999, אבל במשך שנים היא זכתה לאימוץ חלקי - בעיקר מצד דפדפני IE שהיו חלק משמעותי מאוד מהשוק.
התקן שאנו מדברים עליו עכשיו הוא תקן SVG גרסה 2.0 - תקן שעדיין בכתיבה אבל מכיל כמה תוספות משמעותיות מאז הגרסה הקודמת SVG 1.1. העבודה על גרסה 1.2 הופסקה באמצע עבור גרסה 2.0 אך יש באמצע גרסה בשם 1.2 Tiny - אם יצא לכם להיתקל בה.
תקן SVG 2.0 כולל אינטגרציה ל CSS3 ו HTML5 ורשימה של תוספות ושיפורים שונים ומשונים. החלק החשוב בו הוא שהתקן זוכה לתמיכה רחבה מכל הדפדפנים המודרניים (+IE9) התומכים ביכולות הבסיס (שמקורה עוד ב SVG 1.1 + כמה שיפורים) ובהדרגה גם ביכולות מתקדמות יותר של 2.0 (אפקטים, פילטרים, פונטים של SVG ועוד).

SVG עצמו הוא קובץ XML שמתאר ציור וקטורי. בקובץ ה SVG ניתן להשתמש כקובץ חיצוני ל HTML (כגון תמונה מפורמט png) או כתגית SVG שמקוננת בתוך ה markup. הנה דוגמה לתגית SVG מקוננת:

<svg version="1.1" baseProfile="full" xmlns="http://www.w3.org/2000/svg">

  <rect width="100%" height="100%" fill="red" />

  <circle cx="150" cy="100" r="80" fill="green" />

  <text x="150" y="125" font-size="60" text-anchor="middle" fill="white">SVG</text>

</svg>

הנה התוצאה:

כתיבת SVG ידנית יכולה להיות מתישה.
חלק מהיתרון של SVG היא היכולת לצייר את "קוד" ה SVG בעורך חיצוני כגון SVG-Edit או Google Docs Drawing - עורכים חינמיים ואונליין הנחמדים למשימות פשוטות, ועד כלים מקצועיים כגון Inskape (חינמי) או Adobe Illustrator ($$) שיכולים לייצא קובצי SVG. אם אתם רוצים ליצור ויזואליזציה וקטורית לאתר שלכם (כגון פאנל מהודר או מעטפה שטופס יחליק לתוכה) - מה יותר פשוט מלבקש מהמעצב הגרפי שיעבוד בכלי שהוא רגיל אליו ורק ישלח לכם קובץ SVG?

מלבד יכולות ציור פשוטות, SVG כולל:

• טרנספורמציות (דומות ל CSS ו canvas שכבר ראינו)
• יכולות הרכבה של אלמנטים / "ציורים" הנקראות Clipping and Masking והן עשירות מיכולות ה canvas.
• היכולת להשפיע על אלמנטים בתוך ציור ה SVG בעזרת CSS (לדוגמה צבעי הקווים של אזור מסוים).
• היכולת ליצור פונטים חדשים בעזרת SVG (יכולת שלא נתמכת היטב עדיין)
• יכול להיסרק ע"י מנועי חיפוש (SEO) ויכול לתמוך ב Accessibility.
• ואולי היכולת המתקדמת ביותר: להשתמש ב"פילטרים" או "אפקטים" המשפיעים על אלמנטים ב SVG. הכוונה ליכולות שמזכירות תוכנות כגון Adobe Photoshop ויכולות להשיג תוצאות שלא סביר להשיג בעזרת ציור פיקסל-פיקסל (כגון canvas) או הרכבות לוגיות של אלמנטים. דוגמאות מעניינות יכולות להיות הצללה (ניתן בלחיצה לשנות את כיוון ההצללה) או הדמייה של בוקה (Bokeh) - הטשטוש הרקע שיוצרת עדשת מצלמה איכותית וצלמים רבים אובססיביים לגביו.
  למרות ההבטחה הגדולה, SVG Filters דורשים כוח חישוב רב והפילטרים המתקדמים יותר עדיין לא נתמכים ע"י רוב הדפדפנים.

מדוע יש חפיפה בין canvas ל SVG?
קנבס הוצג לראשונה ע"י חברת אפל בגרסאת ה Webkit ששוחררה עם MacOS X. הוא שימש לייצר Desktop Widgets של מערכת ההפעלה (המקבילה ל gadget של Windows Vista) אך היה זמין גם בדפדפן הספארי.
ביקורת רבה הופנתה אל אפל שיצרה "תג" חדש ולא השתמשה בתקן הסטנדרטי - הרי הוא ה SVG. בנוסף התגלה שאפל הגנה בפטנטים על התג החדש - דבר שלא היה ברור לכל כשהציגה אותו.
האם הכוונה היה לאפשר למתחרה כלשהו לאמץ את התקן ואז למצוץ את דמו בעזרת הפטנטים? - לא ברור. אפל לא נראתה טוב בהיבט זה ולאחר זמן קצר תרמה את הפטנטים לשימוש חופשי של W3C - בתנאי שיהפוך לחלק מהתקן ה HTML. כחלק מתנאי ההסכם - התקן אומץ במלואו (גם חלקים שהיוו כפילות ליכולות SVG).

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

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

SVG או Canvas
ל canvas יש יתרון משמעותי בביצועים. כאשר מדובר באנימציות או ציורים בעלי פרטים רבים - כדאי לשקול שימוש ב canvas. מסיבה זו בשימוש במשחקים כמעט ולא תמצאו SVG אלא כמעט ורק canvas.
בכל מקרה אחר - הייתי נוטה לבחור קודם כל ב SVG, אלא אם הוכח אחרת. תחזוקה של קוד canvas יכולה להיות קשה למדי (קוד עמוס פרטים ולא קריא) והיכולת לעבוד בכלי גרפי מתקדם על מנת ליצור חלק נכבד מהוויזואליזציה כ SVG מסייעת ליצור פתרונות מהירים ואמינים יותר.
עדכון: נתקלתי ב Responsive IDE שתומך ב canvas - כלומר מקום בו אתם יכולים לכתוב קוד ג'אווהסקריפט ובכל פעם שתצביעו עם העכבר על ערך מספרי (מידה או צבע) תוכלו לגרור את העכבר, לשנות את הערך ולראות את התוצאה במקום. מדהים! אם אתם מציירים ב canvas זה יכול להיות שיפור פריון אדיר.

כמובן שגם SVG וגם Canvas הם כלים "נמוכים" בהם צריך לעבוד קשה על מנת להשיג מעט. אם מדובר בוויזואליזציה רספונסיבית ומורכבת - כדאי לעבור לרמות הפשטה גבוהות כגון Raphael, Processing או אפילו D3 או Fabric. אלו רק 4 ספריות וכמובן שיש עשרות ספריות נוספות לוויזואליזציה ב JavaScript היכולות להתאים למשימות מגוונות.


----

[א] pixel = גרסך (גרגר מסך) בעברית תקנית - לחובבי העברית שבינכם.

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