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