LOGIN
התחברות או הרשמה
Avatar
להמשך הרשמה ידנית – לחץ על כפתור ההרשמה, להרשמה/כניסה מהירה בעזרת חשבון רשת חברתית – לחץ על הלוגו בכותרת

אפס סיסמה - שכחתי את שם המשתמש

שם משתמש
סיסמה
זכור אותי

he icon   en icon

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

תכונות הטסט: בידול

נכתב על ידי 
חמישי, 07 אוגוסט 2014 11:57
דרגו כתבה זו
(1 הצבעה)

בידול לא בא לבד. הוא דורש קבוצה של טסטים.

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

ה- Waterfall. לפני שנים רבות, כשלא הכרתי תהליך אחר, הייתי כותב מסמכי SDD. אלו מסמכי detailed design משוקצים שכתבנו לקומפוננטות ולפיצ'רים. כמובן שאף אחד לא אהב אותם, המינוח הפורמלי, האורך, ואפילו הריח. אבל היה להם יתרון: כדי לכתוב אותם, צריך לחשוב על הבעיה קודם (כמו TDD). כשקראנו את המסמכים, הם היוו נקודת פתיחה לשאלות "מה יקרה אם..." – מה יקרה אם הקשר יתנתק? מה אם הקומפוננט לא מאותחל בזמן?

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

ובחזרה לעתיד.

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

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

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

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

· סקר קבוצתי. תחילה, חפשו את המקרים החסרים, ואם כן, הוסיפו טסטים בשבילם. עברו על השמות בקבוצה, והשוו אותם אחד לשני. האם הם מבודלים מספיק? האם הם משלימים אחד את השני? אם השמות חופפים, הזיזו את הגורם המבדל שמאלה (באנגלית) כך שאפשר יהיה להבדיל ביניהם בתוך רשימת הטסטים של ה test runner.

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

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

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

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

בפעם הבאה: תחזוקה.

חובה להיות משתמש רשום במערכת בכדי להגיב - ההרשמה/כניסה בכותרת האתר

טיפים

  • בודק - הבן את המודל והאתגרים העיסקיים
    בודק - הבן את המודל והאתגרים העיסקיים בודק - הבן את המודל והאתגרים העיסקיים המוצרים אותם אנו בודקים מיועדים (בין השאר) לקדם את מטרות הארגון בו אנו עובדים, ולנו מחוייבות לעזור בתהליך זה, שהרי לשם כך בעלי העסק מחזיקים בארגון ומעסיקים אותנו, לעיתים…
    קרא עוד...
  • אם נתקלת בבאג במקרה... - חפש באגים דומים
    אם נתקלת בבאג במקרה...  - חפש באגים דומים אם נתקלת בבאג במקרה... או שחזרה תקלה מלקוח - חפש באגים דומים, סביר להניח שפיקששת סדרה שלמה של באגים מאותו סגנון. בתרגום חופשי מהמסמך הבא של Cem Kaner.   ראה המסמך בלינק הבא, כמו גם רשימת Checklists נוספים…
    קרא עוד...
לרשימה המלאה >>