2021-01-02

מתי כדאי להימנע מ Mock Objects?

אני משתדל בבלוג שלי להביא רעיונות חדשים ולא טריוויאלים.

במקרה הזה לא מדובר ברעיון חדש בכלל (הנה פוסט מ 2012) - אבל ככל הנראה בהחלט לא טריוויאלי.

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

אני יכול לתת כמה דוגמאות כאלו, אבל הפעם אתמקד באחת: שימוש שגוי ב Mock Objects.

האמת שהבעיה היא לא דווקא ב Mock Objects, כאשר אומרים "Mock Objects" הכוונה לרוב היא ל Stubs או ל Fakes - אבל ההבחנה לא חשובה. אני מדבר על השימוש המוגזם בכל סוגי ה Test Doubles.


לכאורה, כשלומדים לכתוב Unit Test מתחילים עם בדיקות פשוטות וישירות. כשרוצים "להתקדם" ומחפשים "מה אפשר לעשות מעבר?" מגיעים לעולם של Test Doubles - וה Frameworks השונים שעוזרים ליצור ולנהל אותם (כמו Mockito, SinonJS, MSW, ועוד עשרות), ונוצרת הרגשה שאנו "עושים משהו מתקדם יותר".

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

דווקא המומחים בכתיבת בדיקות-יחידה ממעטים בלהשתמש Mocks, וזו מיומנות שכנראה לא טריוויאלי לרכוש.



האם Mocks הם תמיד רעיון רע?

ברור שלא.

אני אצמד להבחנה של Uncle Bob שמאוד נכונה בעיני:

  • Mocks בין מערכות - הם חשובים, ואף נדרשים בכדי לבצע בדיקות בצורה יעילה.
  • Mocks בתוך מערכת - הם טלאי (Patch). אפשר "לתפור" טלאי פה ושם, וזה לא רע. הבעיה היא כאשר המערכת שלנו הופכת לערימה ענקית של טלאים - וזה קורה לא מעט.


Mocks בין מערכות - הם חשובים, ואף נדרשים בכדי לבצע בדיקות בצורה יעילה

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

כאשר יש לנו בארגון כ 50 מיקרו-שירותים ואנו כותבים בדיקה המפעילה מספר של מיקרו-שירותים (נקרא לבדיקה כזו "System Test") אזי:

  • Scope הבדיקה הוא גדול: בדיקה בודדת מפעילה כנראה מאות או אלפי שורות של קוד.
    • קשה מאוד להתמקד במקרי קצה בתוך ה Flow, והנטיה האנושית היא לא באמת לבדוק מקרי קצה.
    • כשהבדיקה נופלת לא ברור לרוב מה נכשל - צריך להתחיל ולחקור. כלומר: כישלון של בדיקה מוביל לעבודה משמעותית נוספת - לפני שאפשר לתקן את הקוד.
  • סביר יותר ויותר שזמני הריצה של הבדיקה יהיו גבוהים.
    • נחשיב בדיקה שאורכת יותר מ 2 שניות - כבדיקה ארוכה. 2 שניות הן המון זמן מחשוב, אולי כדאי לחשוב עליהן כ 2,000,000,000 ננושניות - ולזכור שמחשבים בימנו מבצעים בננו-שנייה פעולה.
    • כאשר יש לנו הרבה בדיקות (דבר טוב!) והבדיקות אורכות זמן רב => זמן ההמתנה לתוצאות הבדיקה אורך => תדירות הרצת הבדיקות פוחתת => גדל הזמן הממוצע מכתיבה של קוד שגוי - עד שאנו מגלים זאת => Feedback cycle ארוך יותר.
    • "סטנדרט הזהב" להרצה של בדיקות טוען שהמתנה של יותר מ 10 דקות להרצה של בדיקות אינו סביר. לאחרונה אני רואה התפשרות על המדד הזה, ויש כאלו שגם מדברים על 15 דקות של הרצה כזמן סביר / רצוי.
מכאן, אפשר לכתוב הרבה בדיקות, שירוצו הרבה זמן - ולהתדרדר ב Feedback cycle של המפתח.

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

אי אפשר לבדוק מיקרו-שירות ברצינות בלי שהוא יקרא לשירותים שהוא תלוי בהם. לכן חייבים לכתוב Mocks שידמו את המערכת / מיקרו-שירותים האחרים שהשירות שלנו תלוי בהם - בזמן שבודקים את השירות.
ה Scope המצומצם של בדיקת מיקרו-שירות בודד - רק תשפר לנו את המדדים החשובים:
יכולת התמקדות הבדיקה במקרי קצה, זמני איתור תקלה, וזמני הריצה של הבדיקה.

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


Mocks בתוך מערכת - הם טלאי (Patch), שיש לצמצם את השימוש בו.

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

לרוב הבעיה נובעת מכך שאין הפרדה בין:

  • לוגיקה שהשירות מבצע - להלן "Pure Business Logic" (הכתובים כ Pure functions, כמובן)
  • לוגיקה של תקשורת עם שירותים אחרים - להלן "Integration Logic".
ההפרדה הזו קלה בעת כתיבת קוד חדש - וכמעט בלתי אפשרית על גבי קוד קיים שכתוב כך.

כאשר עושים את ההפרדה - קל לכתוב בדיקות יחידה בלי Mocks.
כאשר לא עושים את ההפקדה - קשה מאוד לכתוב בדיקות יחידה, ואז מגיע שימוש מופרז ב Mocks.

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

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

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


העבודה הנוספת בהפרדה בין לוגיקה עסקית ללוגיקה של אינטגרציה:
  • דורשת מודעות ותשומת לב.
  • מוסיפה מעט עבודה בעת הקידוד (נאמר: 10-15%)
אבל:
  • משפרת את המודולוריות (ומכאן - ה Design) של הקוד
  • מאפשר לבדוק אותו בצורה יעילה הרבה יותר, הן מבחינת עומק הבדיקות, והן מבחינת זמן שמושקע בכתיבת בדיקות. 
ברוב המקרים, ההשקעה בהפרדת הקוד תחזיר את עצמה כבר לאחר סיום כתיבת הבדיקות (בדיקות פשוטות יותר = חסכון זמן בעת כתיבת הבדיקות), ובוודאי ובוודאי שתחזיר את עצמה לאורך זמן - כאשר המערכת צריכה לעבור שינויים משמעותיים.

מה הבעיה בשימוש ב Mocks בבדיקות -יחידה?

הנה דוגמה טיפוסית ל Heavily mocked test, ראיתי אינספור כאלו בחיי - ואראה כנראה (אולי הפוסט יעזור?) עוד אינספור בעתיד:



מה הבעיה בבדיקה הזו?
  • היא רצה ומצליחה!
  • אם מחקתי כמה שורות קוד בפונקציה הנבדקת ()doSomething - היא נכשלת. כלומר: היא בודקת משהו.
  • השתמשתי ב mocks frameworks בצורה יעילה - וחסכתי המון קוד לו הייתי כותב את ה Mocks בעצמי.
מה עוד אפשר לבקש?!

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


בעיה: לא ברור מה בדיוק נבדק, מה הצלחת הרצה של הבדיקה - באמת אומרת.

כשאני קורא את קוד הבדיקה, גם בלי obfuscation ושמות משמעותיים - אני מבין שבוצעה פעולה, אבל אני לא יכול לדעת מה חלקה של הפונקציה ()doSomething בעבודה - ומה חלקם של ה Mocks שלה. 

הדרך היחידה שלי להבין מה החלוקה, ומה באמת ()doSomething עושה לאחר שמסירים ממנה את ה Mocks - היא להיכנס לקוד ולקרוא אותו. לפי מספר ה mocks אפשר לנחש כמה זה יהיה קל. הרבה פעמים קריאה שטחית - מפספסת חלק מהעניין.

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

כאשר עושים refactoring במערכת - אי אפשר להבין אלו בדיקות Mock Heavy עומדות לאבד את ערכן.
כאשר הבדיקות הללו נשברות ומתקנים אותן כחלק משינוי - קשה מאוד לוודא שאנחנו משמרים את הערך שלהם. הכלל בגלל שמה שנבדק הוא משתמע ואינו גלוי. 

לכן, זו היא בעיה בתהליך / בתבנית - ולא בקוד הספציפי. 


בעיה: הבדיקה בודקת איך דברים קרו (מבנה), לא מה קרה (התנהגות).


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

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

"האא! הבדיקות לא גילו את זה כי זה היה באג ב SQL" - הוא סוג התירוץ שאנו מספרים לעצמנו במקרים האלו. "אולי כדאי להוסיף גם בדיקה גם על מבנה השאילתא" (בבקשה: לא!)

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

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

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

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



בעיות נוספות

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



לגיקים שבינינו: הכוונה ל Port = "נמל". לא IP Address port :-)




סיכום


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

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

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

חבל לראות את כל הקוד שנכתב בלי הפרדה של לוגיקה - מה שיהפוך את בדיקות היחידה לקשות יותר וליעילות פחות.

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


שיהיה בהצלחה!




8 תגובות:

  1. התגובה הוסרה על ידי המשתמש שכתב אותה.

    השבמחק

  2. אני חושב שאלו נקודות דיון חשובות, אבל:
    - אני חושב שהציטוטים של הדוד בוב מתייחסים בעיקר לclean architecture - או לכל הפחות תפישה של ports and adapters - לא כולם כותבים ככה כדי לשקול מיקומים לMOCK.
    - לעיתים אתה חייב להתממשק לקוד שעדיין לא קיים - והדרך לעשות זאת היא בעזרת MOCK

    אם כך - הטריידאוף לגבי בדיקות הוא ברור:
    Write tests, not many, most of them integration tests [Kent Beck]

    אני לא בטוח שהייתי מסיק מזה משהו לגבי בדיקות יחידה...

    על כל פנים - אחלה מאמר - מראה את היהלום, ייתרונותיו וחסרונותיו באופן ממש ברור.

    השבמחק
    תשובות
    1. היי,

      תודה על הנקודה.
      לגבי הציטוט הראשון, אני חושב שהנקודה היא כללית, כפי שהמשפט מופיע במקור בפוסט הזה: https://blog.cleancoder.com/uncle-bob/2014/05/10/WhenToMock.html

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

      > אם כך - הטריידאוף לגבי בדיקות הוא ברור:
      > Write tests, not many, most of them integration tests [Kent Beck]
      הפתיע אותי שקנת בק יאמר כזה דבר - בתור חסיד של בדיקות-יחידה, כדאי שתבדוק שוב - נשמע שלא הוא אמר, יותר DHH. הייתה את הסשן המפורסם שלו "Is TDD Dead?" - שהעלה את הדיון הזה, וכל הכבוד לו!

      מחק
  3. תודה על הדגשים ועל ההכוונות - בהחלט מאיר את ההבדלים והבעיות שבבחירות להשתמש ב-Mock.
    מה ההמלצה בהקשר הזה לגבי מיקרו-שרותים שניגשים הרבה לדאטאבייס?

    והערה קטנה - patch הוא טלאי ולא תלאי.

    שוב תודה,

    השבמחק
    תשובות
    1. תודה על תיקון העברית - תיקנתי ולמדתי!

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

      בכל זאת אני מעדיף, או לפחות הייתי מנסה:
      1. לבדוק ב component/api test את השירות על ה flow קצה לקצה כולל בסיס הנתונים. דברים יכולים ליפול גם שם, וכמה שאנחנו לא רוצים - יש לנו לוגיקה בבסיס הנתונים (בצורת שאילתות, לפחות).
      2. לבודד את הקוד הלוגי, כך שלא יערב קריאות לבסיס הנתונים - ולבדוק אותו בשלמות.

      תארתי זאת בפוסט הבא: http://www.softwarearchiblog.com/2017/04/

      מחק
  4. Meni Shmueli4/1/21 11:46

    פוסט מצוין!

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

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

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

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

      הוא ה ROI הטוב ביותר שמצאתי עד יום זה.

      מחק
  5. אחלה מאמר.
    מה דעתך על להוסיף embedded database לטסטים?
    אני חושב שזאת דרך טובה לבדוק שגם שאילתות ה SQL מבצעות את העבודה כמו שצריך. מצד שני, אין צורך להשוות ממש את המחרוזת של השאילתא.

    השבמחק