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

1. בדיקת Utility Functions גנריות

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

דוגמה טובה היא הספריה lodash שכוללת בנוסף לכל קבצי המקור גם תיקיית test שמכילה קובץ בדיקה שמתאים לכל קובץ מקור. רצוי לראות את הבדיקות שלהם כאן: https://github.com/lodash/lodash/tree/master/test.

2. בדיקת קומפוננטות גנריות

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

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

3. בדיקת Custom Hooks

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

קחו לדוגמה את useCookies הוק שמאפשר לקומפוננטה לקרוא מידע מ Cookies. יש להם קובץ בדיקה די מקיף כאן: https://github.com/reactivestack/cookies/blob/master/packages/react-cookie/src/tests/useCookies-test.js. הנה דוגמה לבדיקה ממנו:

    it('update when a cookie change', () => {
      const cookies = new Cookies();
      const node = document.createElement('div');

      const toRender = (
        <CookiesProvider cookies={cookies}>
          <TestComponent />
        </CookiesProvider>
      );

      act(() => {
        cookies.set('test', 'big fat cat Pacman');
        ReactDOM.render(toRender, node);
      });

      expect(node.innerHTML).toContain('big fat cat Pacman');

      act(() => {
        cookies.set('test', 'mean lean cat Suki');
        ReactDOM.render(toRender, node);
      });

      expect(node.innerHTML).toContain('mean lean cat Suki');
    });

זאת כבר בדיקה שיותר קשה לכתוב מאשר בדיקת קומפוננטה רגילה, וכמובן יותר קשה לכתוב מאשר בדיקה של Pure Function. למרות הקושי בדיקת Custom Hooks נותנת ערך כי זה משהו שמשתמשים בו בהרבה מקומות במערכת וכשיש עליו סט מקיף של בדיקות יחידה אנחנו מרגישים יותר בנוח לשנות אותו.

4. מסלולי קוד שקשה להגיע אליהם אחרת

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

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

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