יום חמישי, 21 ביולי 2016

בדיקות יחידה, Unit Test

כבודקי תוכנה, אנו אחראים בעצם לאיכות המוצר. אפשר לראות זאת בהיקף הצר של המילה, כלומר שאנו אחראים על הרצת התוכנה ושאיפה לגילוי כלל הבאגים שנמצאים בתוכה בפרק הזמן שהצבנו לפנינו ובעלות המתוכננת.
אבל אפשר לראות את תפקידנו בהיקף רחב יותר של המילה, כלומר אחראים לאיכות המוצר בכל שלביו, ואני לא מתכוון רק לבדיקת המסמכים וכו', אלא וידוא שתהליך הפיתוח בכללו נעשה בדרך משביעת רצון. בעצם כולנו באג'ייל אחראיים לאיכות המוצר. אגב, אני לא רואה הבדל בין המקרים, כלומר לדעתי אם התהליכים לא יהיו נכונים בסופו של דבר המערכת תצא עם סוג זה או אחר של באג, בין אם זהו באג מובהק ובין אם מדובר בכך שהדרישות לא מולאו לחלוטין וכד'.
מסיבה זו אני אכנס מעט לתהלך שבד"כ אנו לא מעורבים בו, ה-unit test, להלן UT.
  
הגדרה: ה-UT אמור לבדוק יחידה אינדיבידואלית על-ידי אנשי הפיתוח. זוהי היחידה הקטנה ביותר שניתנת לבדיקה, או אפילו חיבור לוגי של כמה יחידות. זו יכולה להיות תוכנית פשוטה, פונקציה, פרוצדורה, מתודה או מודול. למשל יחידה שמקבלת שם משתמש, שולחת לבסיס הנתונים, מקבלת אישור או דחייה ומעבירה את התוצאה הלאה.
אחריות וביצוע: הפיתוח. היגיוני מאוד, אבל זה לא אומר שאנו לא יכולים לעזור לבדיקות האלה. אין סיבה שלא נשב ליד המפתח ונבין את התפקוד של היחידה ונציע סוגי בדיקות. למשל מקרי קצה אני מנח שלרוב יהיה לנו קל ח=לחשוב על מקרים כאלה אולי יותר מאשר למפתח. חשוב לי מאוד שלא נפתור דברים כאלה כאילו זו אינה אחריותינו, כל עוד אנו יכולים באמת לתרום.
בד"כ בדיקות אלה אוטומאטיות, יכולות להיות "קופסא לבנה" וגם "קופסא שחורה". כמו כן בדיקות אלו יכולות וצריכות להיות פרוגרסיביות ורגרסיביות.
מומלץ לכתוב את ה-UT לפני כתיבת הקוד עצמו.
 ×‘דיקות יחידה, Unit Test
בדיקות יחידה, Unit Testבדיקות יחידה, Unit Test
  
מטרות: 
  • לבדוק שליחידה יש היכולות הנדרשות;  
  • שהיא מקבלת ומוסרת את הנתונים הנכונים;  
  • מתממשקת נכון;  
  • זיהוי של בעיות שניתן לגלות רק ברמה הזו. למשל אני מכיר מקרה שהתשובה שהיחידה סיפקה היתה נכונה אך כפולה. בבדיקות של המוצר היה קשה מאוד לגלות זאת, אבל ייתכנו מקרים מסוימים אצל הלקוח שהפארסינג היה פשוט נפסק כתוצאה מכך. 
ולבסוף: שהיחידה מוכנה (לאחר תיקון כל הבאגים) לאינטגרציה.
  
יש לזכור את היתרון העצום של מציאת בעיה בשלב זה: החיסכון בזמן. זיהו בעיה בשלב זה כשרק אדם אחד מעורב, ובנוסף ברור מיידית מעיין נובעת ההתנהגות הבלתי רצויה. במקרה של קבלת מוצר שיש בו באג (כמו מה שקורה בחדר הבדיקות) האנליזה עלולה להיות ממושכת לא רק באפיון מדויק של התקלה שהבודקים עושים, אלא גם באנליזה של הפיתוח לגבי מקורה של הבעיה הנ"ל.
  
בדיקות טובות של UT הן:
  • אוטומאטיות;
  • קלות לניהול;
  • קלות להרצה;
  • שומרות לוגים;
  • מייצרות סטטיסטיקות;
  • כוללות בדיקות שליליות, טיפול בבעיות;
  • ערכי קצה וערכי default;
  • ארגומנטים לא ואלידיים (טקסט במקום מספר). 


כמו תמיד, יש לעשות review על כל בדיקה ומידי פעם על ה-scope של הבדיקות, כיסוי האזורים וכד'. שני הדברים האחרונים – בתיאום עם מחלקת הבדיקות.
  
נקודות נגד:
מאריך את זמן הפיתוח, לא תמיד קל ליישום.
  
הערה: נעזרתי בויקי באנגלית: https://en.wikipedia.org/wiki/Unit_test שם יש חלק נוסף הקושר בין ה-UT ל-Extreme Programming.

אין תגובות:

הוסף רשומת תגובה

רשומות פופולריות