קובעים מה צריך לבדוק ומה אפשר להוציא משיקול.
במאמר הקודם התייחסנו ליסודות של תרחישי בדיקה ולתוכן שהם צריכים להכיל. במאמר הזה נסביר לעומק איך יוצרים תרחישי בדיקה מנקודת מבט טכנית, ונפרט מה צריך לכלול בכל בדיקה וממה כדאי להימנע. בעיקרון, תלמדו מה כדאי לבדוק ומה לא כדאי לבדוק.
הנחיות כלליות ודפוסים
חשוב לציין שדוגמאות ונקודות ספציפיות הן חיוניות, בין שאתם מבצעים בדיקות יחידה, שילוב או מקצה לקצה. אפשר וצריך להחיל את העקרונות האלה על שני סוגי הבדיקות, ולכן הם נקודת התחלה טובה.
לשמור על פשטות
כשכותבים בדיקות, אחד הדברים החשובים ביותר לזכור הוא לשמור על פשטות. חשוב להביא בחשבון את קיבולת המוח. קוד הייצור הראשי תופס נפח משמעותי, כך שיש מעט מקום ליותר מורכבות. זה נכון במיוחד לצורכי בדיקה.
אם יש פחות מקום פנוי בראש, יכול להיות שתרגישו יותר רגועים במהלך הבדיקה. לכן חשוב לתת עדיפות לפשטות בבדיקות. למעשה, שיטות הבדיקה המומלצות של Yoni Goldberg ל-JavaScript מדגישות את החשיבות של הכלל הזה – הבדיקה צריכה להרגיש כמו עוזרת ולא כמו נוסחה מתמטית מורכבת. במילים אחרות, אתם אמורים להבין את מטרת הבדיקה במבט ראשון.
כדאי לשאוף לפשטות בכל סוגי הבדיקות, ללא קשר למורכבות שלהן. למעשה, ככל שהבדיקה מורכבת יותר, כך חשוב יותר לפשט אותה. אחת הדרכים להשיג זאת היא באמצעות עיצוב בדיקה פשוט, שבו הבדיקות פשוטות ככל האפשר, ורק מה שצריך לבדוק. המשמעות היא שכל בדיקה צריכה להכיל רק מקרה בדיקה אחד, והמקרה הזה צריך להתמקד בבדיקת פונקציונליות או תכונה ספציפית אחת.
כדאי לחשוב על זה מנקודת המבט הזו: כשקוראים בדיקה שנכשלה, צריך להיות קל לזהות מה השתבש. לכן חשוב שהבדיקות יהיו פשוטות וקלות להבנה. כך תוכלו לזהות בעיות במהירות ולפתור אותן כשהן מתרחשות.
בודקים מה שווה את זה
תכנון הבדיקה השטוח גם מעודד אתכם להתמקד בבדיקה ועוזר לוודא שהבדיקות שלכם משמעותיות. חשוב לזכור: לא כדאי ליצור בדיקות רק כדי להגדיל את הכיסוי – תמיד צריכה להיות להן מטרה.
לא בודקים את פרטי ההטמעה
אחת מהבעיות הנפוצות בבדיקות היא שבדרך כלל הבדיקות מיועדות לבדוק פרטי הטמעה, כמו שימוש בבוררים ברכיבים או בדיקות מקצה לקצה. פרטי ההטמעה מתייחסים לדברים שבדרך כלל משתמשי הקוד לא ישתמשו בהם, לא יראו אותם או אפילו לא ידעו עליהם. המצב הזה עלול להוביל לשתי בעיות עיקריות בבדיקות: תוצאות שליליות כוזבות ותוצאות חיוביות כוזבות.
תוצאות שליליות שגויות מתקבלות כשהבדיקה נכשלת, למרות שהקוד שנבדק תקין. מצב כזה יכול לקרות כשפרטי ההטמעה משתנים בגלל שינוי מבני בקוד האפליקציה. לעומת זאת, תוצאות חיוביות כוזבות מתרחשות כשבדיקה עוברת, למרות שהקוד שנבדק שגוי.
אחת מהדרכים לפתור את הבעיה הזו היא להביא בחשבון את סוגי המשתמשים השונים שיש לכם. הגישה של משתמשי הקצה והמפתחים עשויה להיות שונה, והם עשויים לקיים אינטראקציה עם הקוד באופן שונה. כשמתכננים בדיקות, חשוב להביא בחשבון מה המשתמשים יראו או ייכנסו איתו לאינטראקציה, ולהפוך את הבדיקות לתלויות בדברים האלה במקום בפרטי ההטמעה.
לדוגמה, בחירה בסלקטורים פחות נוטים לשינוי יכולה לשפר את האמינות של הבדיקות: מאפייני נתונים במקום סלקטורים ב-CSS. מידע נוסף זמין במאמר של Kent C. במאמר של Dodds בנושא הזה, או כדאי לחכות – בקרוב יפורסם מאמר בנושא הזה.
בדיקת מודלים: לא לאבד שליטה
יצירת מודלים מדומים היא מושג רחב שמשתמשים בו בבדיקות יחידה ולפעמים בבדיקות שילוב. היא כוללת יצירת נתונים או רכיבים מזויפים כדי לדמות יחסי תלות שיש להם שליטה מלאה על האפליקציה. כך אפשר לבצע בדיקות מבודדות.
שימוש במודלים מדומים (mock) בבדיקות יכול לשפר את היכולת לחזות את התוצאות, את הפרדת הבעיות ואת הביצועים. בנוסף, אם אתם צריכים לבצע בדיקה שדורשת מעורבות אנושית (למשל אימות דרכון), תצטרכו להסתיר אותה באמצעות בדיקה מדומה. מכל הסיבות האלה, מומלץ להשתמש בתבניות לדוגמה.
עם זאת, בדיקות מודלים יכולות להשפיע על הדיוק של הבדיקה כי הן בדיקות מודלים, ולא חוויות משתמש אמיתיות. לכן חשוב להפעיל שיקול דעת כשמשתמשים במודלים מדומים ובסטאבים.
האם כדאי להשתמש במודלים מדומים בבדיקות מקצה לקצה?
באופן כללי, לא. עם זאת, לפעמים יצירת מודלים יכולה להציל את החיים – אז לא נפסול אותה לגמרי.
נסו לדמיין את התרחיש הבא: אתם כותבים בדיקה לתכונה שכוללת שירות של ספק תשלומים של צד שלישי. אתם נמצאים בסביבת חול שהם סיפקו, כלומר לא מתבצעות עסקאות אמיתיות. לצערנו, ארגז החול לא פועל כראוי, ולכן הבדיקות נכשלות. ספק התשלומים צריך לבצע את התיקון. כל מה שאפשר לעשות הוא להמתין עד שהבעיה תיפתר על ידי הספק.
במקרה כזה, מומלץ לצמצם את התלות בשירותים שאין לכם שליטה עליהם. עדיין מומלץ להשתמש בהדמיה בזהירות בבדיקות אינטגרציה או בבדיקות מקצה לקצה, כי היא מורידה את רמת האמון בבדיקות.
פרטי הבדיקה: מה כדאי ומה לא כדאי לעשות
אז, בסך הכול, מה מכיל המבחן? האם יש הבדלים בין סוגי הבדיקות? נבחן לעומק כמה היבטים ספציפיים שמותאמים לסוגים העיקריים של בדיקות.
מה נכלל בבדיקת יחידה טובה?
בדיקת יחידה אידיאלית ויעילה צריכה:
- להתמקד בהיבטים ספציפיים.
- לפעול באופן עצמאי.
- תרחישים בקנה מידה קטן.
- כדאי להשתמש בשמות תיאוריים.
- פועלים לפי התבנית AAA אם רלוונטי.
- להבטיח כיסוי מקיף של הבדיקות.
| מה צריך לעשות ✅ | לא מומלץ ❌ |
|---|---|
| כדאי שהבדיקות יהיו קצרות ככל האפשר. בודקים דבר אחד לכל מקרה בדיקה. | כתיבה של בדיקות על יחידות גדולות. |
| תמיד חשוב לשמור על הבדיקות מבודדות ולבצע מודלים של הדברים שדרושים לכם מחוץ ליחידה. | לכלול רכיבים או שירותים אחרים. |
| חשוב לשמור על הבדיקה כעצמאית. | להסתמך על בדיקות קודמות או לשתף נתוני בדיקה. |
| כדאי לכלול תרחישים ומסלולים שונים. | כדאי להגביל את עצמכם לבדיקה של התרחיש הרצוי או לבדיקה שלילית לכל היותר. |
| כדאי לתת שמות תיאורים לבדיקות, כדי שתוכלו לראות מיד מהן מטרות הבדיקה. | בדיקה לפי שם הפונקציה בלבד, לא מספיק תיאורי כתוצאה מכך: testBuildFoo() או testGetId(). |
| כדאי שתתמקדו בהגדלת הכיסוי של הקוד או בהרחבת מגוון תרחישי הבדיקה, במיוחד בשלב הזה. | צריך לבדוק מכל הכיתות ועד לרמת מסד הנתונים (I/O). |
מה נכלל בבדיקת שילוב טובה?
לבדיקת שילוב אידיאלית יש גם כמה קריטריונים משותפים לבדיקות יחידה. עם זאת, יש כמה נקודות נוספות שחשוב להביא בחשבון. בדיקת אינטגרציה טובה צריכה:
- הדמיה של אינטראקציות בין רכיבים.
- כדאי לכלול תרחישים מהעולם האמיתי ולהשתמש במודלים מדומים או בסטאבים.
- חשוב להביא בחשבון את הביצועים.
| מה צריך לעשות ✅ | לא מומלץ ❌ |
|---|---|
| בדיקת נקודות השילוב: מוודאים שכל יחידה פועלת בצורה חלקה כשמשולבת עם היחידות האחרות. | בודקים כל יחידה בנפרד – זה למה נועדו בדיקות היחידה. |
| בדיקת תרחישים מהעולם האמיתי: שימוש בנתוני בדיקה שמבוססים על נתונים מהעולם האמיתי. | שימוש בנתוני בדיקה חוזרים שנוצרו באופן אוטומטי או בנתונים אחרים שלא משקפים תרחישים לדוגמה בעולם האמיתי. |
| כדי לשמור על שליטה בבדיקות המלאות, כדאי להשתמש במודלים מדומים ובסטאבים של יחסי תלות חיצוניים. | יצירת יחסי תלות בשירותי צד שלישי, למשל בקשות רשת לשירותים חיצוניים. |
| כדאי להשתמש בתהליך ניקוי לפני ואחרי כל בדיקה. | שכחתם להשתמש באמצעי ניקוי בתוך הבדיקות. אחרת, זה עלול להוביל לכשלים בבדיקות או לתוצאות חיוביות כוזבות, בגלל חוסר בידוד מתאים של הבדיקות. |
מה נכלל בבדיקת 'קצה-לקצה' טובה?
בדיקה מקיפה מקצה לקצה צריכה:
- שכפול של אינטראקציות של משתמשים.
- לכלול תרחישים חיוניים.
- שמשתרעות על פני כמה שכבות.
- ניהול פעולות אסינכרוניות.
- מאמתים את התוצאות.
- צריך להביא בחשבון את הביצועים.
| מה צריך לעשות ✅ | לא מומלץ ❌ |
|---|---|
| שימוש בקיצורי דרך מבוססי-API. מידע נוסף | משתמשים באינטראקציות בממשק המשתמש בכל שלב, כולל ה-hook beforeEach. |
| לפני כל בדיקה, כדאי להשתמש בתהליך ניקוי. חשוב להקפיד על בידוד הבדיקה יותר מאשר בבדיקות יחידה ובדיקות אינטגרציה, כי יש כאן סיכון גבוה יותר לתופעות לוואי. | שכחתם לנקות אחרי כל בדיקה. אם לא תנקטו פעולה כדי לנקות את המצב, הנתונים או תופעות הלוואי שנותרו, הם ישפיעו על בדיקות אחרות שיתבצעו מאוחר יותר. |
| להתייחס לבדיקות מקצה לקצה כאל בדיקות מערכת. כלומר, צריך לבדוק את כל סטאק האפליקציה. | בודקים כל יחידה בנפרד – זה למה נועדו בדיקות היחידה. |
| להשתמש בזיוף מינימלי או לא להשתמש בו בכלל בתוך הבדיקה. כדאי לחשוב היטב אם רוצים ליצור מודלים מדומים של יחסי תלות חיצוניים. | להסתמך במידה רבה על מודלים מדומים. |
| כדאי להביא בחשבון את הביצועים ואת עומס העבודה. לדוגמה, לא כדאי לבדוק תרחישי בדיקה גדולים מדי באותו בדיקה. | לכסות תהליכי עבודה גדולים בלי להשתמש בקיצורי דרך. |