בדיקות אוטומטיות אינן התשובות להכל

TDD – ‏Test Driven Development היא גישה או תפיסה האומרת כי כל שורת קוד אותה אנחנו מפתחים, אנחנו קודם יוצרים לה בדיקה שתיכשל, ואז כותבים את הקוד שיגרום לבדיקה לעבור, ובכך מונעים הרבה מאוד בעיות בפיתוח, וכן יכולים לזהות ריגרסיה כאשר זו מגיעה בקוד. כבר כתבתי על הנושא מספר פעמים כאן בבלוג.

לאחרונה היה באג בספרייה בשם ActiveRecord, אשר במצב מאוד מיוחד, היה ניתן לגרום למתודה find_by_‎ לבצע SQL Injection. הבאג ד"א היה ניתן לניצול רק במצבים מאוד מדוייקים של שימוש במתודות, ולכן אם לא היה שימוש בגישה מסויימת, לא היה ניתן לנצל אותם, אבל הבאג היה עדיין קיים, והמליצו לכולם לשדרג לתיקון הבעיה.

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

כלומר מרבית השימושים בActiveRecord מעולם לא היו גורמים לבעיות או מסכנים אתר מסויים ב SQLi. ועכשיו נשאלת השאלה: האם TDD מסוגל לעלות על מקרה קצה כל כך קיצוני ?

האם ב99.9 אחוז מהבדיקות שתעשה הבדיקה תצא תקינה, האם תדע לכתוב את הבדיקה 0.1 בה תצליח לגלות באג ?

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

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

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

3 מחשבות על “בדיקות אוטומטיות אינן התשובות להכל

  1. אלי

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

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

    –אלי

    1. ik_5 מאת

      אכן, זה בדיוק מה שניסיתי להסביר כאן.

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

  2. אורןה

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

    שתי הערות על TDD מזווית מבטי:
    1. בראייתי TDD לא מגדיר מה רמת הכיסוי צריכה להיות; הוא מגדיר שיטה של בדיקה לפני קידוד, אבל אני לוקח את החופש להחליט מה אני מכסה בבדיקה ומה לא. והחלטתי כברירת המחדל היא *לא* לכתוב טסט. אני מחליט לכתוב טסט לא מעט, אבל רק כשאני מרגיש שיש בזה תועלת.

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

כתיבת תגובה

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

הלוגו של WordPress.com

אתה מגיב באמצעות חשבון WordPress.com שלך. לצאת מהמערכת / לשנות )

תמונת Twitter

אתה מגיב באמצעות חשבון Twitter שלך. לצאת מהמערכת / לשנות )

תמונת Facebook

אתה מגיב באמצעות חשבון Facebook שלך. לצאת מהמערכת / לשנות )

תמונת גוגל פלוס

אתה מגיב באמצעות חשבון Google+ שלך. לצאת מהמערכת / לשנות )

מתחבר ל-%s