השמות שניתנים לבדיקות מסוגים שונים בדרך כלל כוללים נושאים משותפים ב-codebase, אבל אין להם הגדרות קפדניות במיוחד. קורס זה מספק הנחיות לגבי המשמעות של כל סוג בדיקה, אבל מקורות מידע אחרים עשויים לספק הגדרות שונות.
בדפים הקודמים היו דוגמאות לבדיקות יחידה ולבדיקות רכיב (בדוגמה שלנו, התייחסנו לרכיב של תגובה). אנחנו יכולים למקם את שתי התצורות האלה בפירמידת הבדיקה שלנו (או בצורה אחרת!), כי הן מורכבות מעט מאוד והן מהירות להפעלה, אבל יכול להיות שהן פחות שימושיות כמו בדיקת שילוב מורכבת יותר.
סוגים נפוצים של בדיקות
בדיקות של יחידות
בדיקות היחידה הן הקטנות ביותר. בדרך כלל משתמשים בהם כדי לבדוק חלקים קטנים בקוד, או קוד ללא שמירת מצב בלבד, באופן כמעט מתמטי: אם אני מספק לקוד את הקלטים X, Y ו-Z, הפלט שלו צריך להיות A, B ו-C.
לקוד עם בדיקות יחידה בדרך כלל לא יהיו יחסי תלות חיצוניים, כמו אחזור מרשת או שימוש מרומז בפונקציות או בספריות אחרות. זהו צומת עץ של הקוד, שאפשר "לחתוך" ולבדוק אותו לבד.
על אף שבדיקות יחידה נוטות לכתוב ולהפעיל במהירות, תמיד ייתכן שבדיקה של יחידות קוד קטנות לא תיתן מידע שימושי. לעיתים קרובות, חוסר אינטראקציה של יחידת קוד עם קוד אחר, פירושו שעדיף לבצע בדיקה ברמה גבוהה יותר כדי להפחית את הסיכון.
בדיקות רכיבים
למפתחי אתרים יש עומס יתר בשם 'רכיב', שמשמעותו לעיתים קרובות היא רכיב שגלוי למשתמש, כמו רכיב React או רכיב אינטרנט. ההגדרה הכללית יותר היא קטע עבודה שניתן לבדוק, לדוגמה, סיווג עם תלות חיצונית. כדי לבדוק את הרכיב הזה ביעילות, צריך לדמות את התלות שלו או לדלג עליהן.
מכיוון שהשיטות המודרניות לפיתוח אתרים מבוססות על העיקרון של רכיב, בדיקות של רכיבים הן דרך מעשית לחשוב על הבדיקה: לדוגמה, אתם עשויים להחליט שצריך לבדוק כל רכיב. גם קל לעקוב אחרי בדיקות הרכיבים בהקשרים שבהם מפתח יחיד או צוות קטן מצהיר על בעלות ברורה על רכיב. אבל יכול להיות קשה לדמות יחסי תלות מורכבות.
בדיקות שילוב
לרוב, הם בודקים קבוצה קטנה של רכיבים, מודולים, מערכות משנה או חלקים משמעותיים אחרים בקוד כדי לוודא שהם פועלים כראוי. זו הגדרה מעורפלת מאוד. למפתחי אתרים, נניח שהקוד שאתם בודקים הוא לא ה-build האמיתי של האתר (או אפילו קרוב אליו), אבל עדיין מחבר רכיבים קשורים שונים במערכת.
זה יכול לכלול גם יחסי תלות 'אמיתיים', כמו מסד נתונים חיצוני במצב בדיקה, במקום מדומה בלבד. לדוגמה, במקום לציין ש-query() תמיד יחזיר את אותן שתי רשומות, בדיקת השילוב יכולה לאשר שמסד הנתונים של הבדיקה מכיל משהו. הנתונים עצמם פחות חשובים, אבל עכשיו בודקים שאפשר להתחבר למסד נתונים ולשלוח אליו שאילתות.
אפשר לכתוב בדיקות שילוב פשוטות יחסית עם השלכות רחבות, שאותן ניתן לבדוק באמצעות טענות נכונות, כי פעולה אחת שמקושרת לרכיבים שונים יכולה לגרום לסדרת השפעות שניתנות למדידה.
לכן בדיקות שילוב יכולות להדגים בפועל שהמערכת המורכבת תפעל כמו שצריך. עם זאת, קשה לכתוב ולתחזק אותן, והן עלולות ליצור מורכבות מיותרת. לדוגמה, כתיבת
FakeUserService לבדיקת שילוב מוסיפה את הדרישה שגם ה-API וגם
RealUserService צריכים להטמיע UserService.
בדיקות עשן
אלו בדיקות שאמורות להסתיים במהירות רבה כדי לקבוע אם ה-codebase שלכם במצב הגיוני. בפועל, מדובר בעיקר בביצוע בדיקות פשוטות על קוד עם השפעות נרחבות על החוויה שלכם.
לדוגמה, באפליקציית אינטרנט גדולה שמחוברת לחשבון, אפשר לוודא שמערכת ההתחברות והאימות פועלת, כי בלעדיה לא ניתן להשתמש באפליקציה ולא ניתן לבצע בדיקות נוספות.
מומלץ להריץ בדיקות עשן ב-codebase גדול באמצעות הסקריפט test של package.json. בדיקה ידנית יכולה גם לפעול כסוג של בדיקת עשן.
בדיקות רגרסיה
בדיקות רגרסיה הן סוג של בדיקות עשן שמבטיחות שהתכונות הקיימות ימשיכו לפעול, או שלא החזרה של באגים ישנים אחרי השקה חדשה או פיתוח של תכונות אחרות.
זה קשור לקונספט של פיתוח מבוסס-בדיקה (TDD). מקרי בדיקה שנכתבו כדי להפעיל באג באופן מפורש ומשתמשים בהם בהמשך כדי לוודא תיקון של הבאג, נחשבים למקרי רגרסיה, כי קיומם אמור למנוע את החזרה של אותו באג.
עם זאת, בדיקת רגרסיה יכולה להיות בעיה ללא פתרון מצוין. זהו מונח שצוטט לעיתים קרובות על ידי צרכים עסקיים: מאחר שהתכונות נוצרות, חשוב שהתכונות הישנות לא יתקלקל. בסיס קוד שנבדק היטב אמור להיות מסוגל לתחזק את ה-codebase, אבל לא תמיד אפשר לשמור על אותו בסיס קוד אמיתי. נעסוק בכך בסעיפים נוספים בעתיד.
בדיקות חזותיות
בדיקות חזותיות כוללות צילומי מסך או סרטונים של מצב אתר כדי לבדוק מצב תקין ידוע (כמו צילום מסך קודם) מול הרצת הבדיקה הנוכחית. מטבעו, יש להפעיל דפדפן אמיתי כדי שיוכל לעבד HTML, CSS וחלקים אחרים של האתר.
במקום לבצע בדיקה חזותית של בדיקות מקצה לקצה שמפעילות את כל בסיס הקוד, כדאי ליצור "רתמות" של HTML שמעבירות רק רכיבים מסוימים, במיוחד בגדלים שונים של מסכים כדי להפעיל את ממשקי משתמש רספונסיביים. זה מורכב יותר מאשר רק שימוש ב-JSDOM או ב-frameworks דומות.
בדיקות חזותיות שנכשלו יכולות להיות סימן טוב לסוגים אחרים של תקלות. עם זאת, ממשקי משתמש מורכבים עלולים להיכשל בבדיקות חזותיות מסיבות שלא קשורות לתכונות שמנסים לבדוק, כמו תכונות חדשות שמשנות את המראה של ממשק המשתמש, או אפילו גרסה חדשה של מערכת ההפעלה שמציגה אמוג'י באופן שונה מגרסאות קודמות.
בדיקות מקצה לקצה
לרוב, הבדיקות מקצה לקצה נמצאות בחלק העליון של פירמידת הבדיקות. הן מתארות אינטראקציה שלמה עם אפליקציית האינטרנט או האתר, שלרוב מרוכזת סביב תכונה מסוימת, ובדרך כלל הן פועלות בדפדפן שנשלט על ידי סוכן כמו WebdriverIO, Sleenium או Puppeteer, שיכול להריץ את קוד ה-codebase יותר או פחות ממה שנפרס בייצור (למרות שהם בדרך כלל מוצגים ב-localhost).
בהתאם לאתר שלכם, יכול להיות שתצטרכו להתחבר לחשבון כמשתמש בדיקה, לבצע פעולות חשובות ולאשר שהאתר או המערכת נמצאים במצב הנכון. בקטעים נוספים נעסוק בדוגמאות נוספות של בדיקות מהסוג הזה, כי הן יכולות להיות עוצמתיות מאוד, אבל לפעמים מסובכות לתחזק אותן.
יש טקטיקות פשוטות שנועדו לפשט אותן. למשל, אפשר לצמצם את היקף ההרשאות או לדמות רכיבים ספציפיים במקרים הרלוונטיים. לדוגמה, אם משתמשים צריכים להיכנס לאתר שלכם, אבל כניסה היא לא התכונה שאתם בודקים, תוכלו להגדיר סימון לסביבות בדיקה שמאפשר לבקר הבדיקה לפעול כמשתמש בלי להיכנס לחשבון או ליצור את קובצי ה-cookie המשויכים.
בדיקות מקצה לקצה יכולות להיות דרכים עוצמתיות מאוד לבדוק מקטעים עצומים של ה-codebase שלכם בבת אחת, אבל בדיקות בקנה מידה גדול כאלה עלולות להיות רעננות או לא אמינות בגלל התלות שלהן במערכות חיצוניות. הם גם יכולים להשאיר הרבה נתוני בדיקה במסד הנתונים, למשל, אם, למשל, כל בדיקה יוצרת רשומה או משנה אותה. צבירת נתונים מיותרים כאלה יכולה להקשות על הקביעה איך בדיקה נכשלה.
בדיקת API
בדיקות API יכולות להתייחס לאישור ההתנהגות של ממשקי ה-API שהתוכנה מספקת, או לגישה לממשקי API של העולם האמיתי (כנראה שבאמת היו פעילים) כדי לאשר את ההתנהגות שלהם. בכל מקרה, הבדיקה נוטה לבדוק את ההפשטות בין המערכות – איך הן יתקשרו בסופו של דבר זו עם זו – מבלי לשלב אותן בפועל כמו בבדיקת שילוב.
הבדיקות האלה יכולות לשמש כנקודת התחלה בסיסית לבדיקות אינטגרציה, ללא התקורה של הפעלת המערכות שביניהן בודקים את החיבורים. עם זאת, הבדיקות של מערכות בעולם האמיתי יכולות להיות בעייתיות.
סוגים אחרים
יש מגוון גישות נוספות לבדיקה שעשויות להיות שימושיות, בהתאם למקור שלכם. הנה כמה דוגמאות מעניינות:
- בדיקות ידניות.
- בדיקת קבלה, שהיא סוג של בדיקה ידנית שפופולרית על ידי Agile, מאשרת שהמוצר "עונה על צורכי המשתמש".
- בדיקת כאוס היא הזנת נתונים אקראיים כדי לראות מה קורה, כדי לוודא שהאתר לא יקרוס אם מזינים נתונים שגויים.
- כאשר בודקים באופן מכוון כשלים במערכות מורכבות, כמו כשלים ברשת, כדי לוודא שהקוד בבדיקה מגיב באופן מבוקר,
- בדיקת build מאשרת שניתן ליצור ארטיפקטים של גרסת build של קוד בסיס על ידי בדיקה שהם קיימים או מהו התוכן שלהם. סוג הבדיקה הזה יכול להיות שימושי לבדיקת הפלט של מערכת ניהול תוכן מורכבת.
כיסוי קוד
ניתן למדוד את אחוז הקוד שנבדק בבדיקות אוטומטיות, ולדווח על כך כנתון סטטיסטי לאורך זמן. לא מומלץ להתמקד בכיסוי 100% הקוד, כי חשיפה כזו עלולה לגרום לתקורה מיותרת וגם לבדיקות פשטות או בדיקות עם תכנון לקוי, שלא עוסקות בתרחישים העיקריים לדוגמה.
הכיסוי עצמו יכול להיות גם כלי שימושי כשכותבים בדיקות או עובדים עליהן, במיוחד בדיקות שילוב. הצגת פירוט של הקוד שנבדק בבדיקה אחת באחוזים או שורה אחר שורה, מאפשרת לכם להבין מה חסר או מה אפשר לבדוק בהמשך.
משאבים
בחינת ההבנה
אילו מסוגי הבדיקות הבאים ידועים?