איפה פועלות הבדיקות

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

סקריפט של דרישה מוקדמת

לפרויקטים של אינטרנט בדרך כלל יש קובץ תצורה — קובץ package.json — שמוגדר על ידי npm, pnpm, Bun או קבצים דומים. קובץ התצורה מכיל את יחסי התלות של הפרויקט, מידע אחר וסקריפטים מסייעים. סקריפטים המסייעים האלה יכולים לכלול מידע על הבנייה, ההפעלה או הבדיקה של הפרויקט.

ב-package.json צריך להוסיף סקריפט בשם test שמתאר איך להריץ את הבדיקות. הדבר חשוב כי כשמשתמשים ב-npm או בכלי דומה, לסקריפט הבדיקה יש משמעות מיוחדת. הסקריפט הזה יכול רק להפנות לקובץ יחיד שמציג חריג, משהו כמו node tests.js, אבל מומלץ להשתמש בו כדי להפנות להרצת בדיקה מבוססת.

אם משתמשים ב-Vitest בתור מפעיל הבדיקה, קובץ package.json ייראה כך:

{
  "name": "example-project",
  "scripts": {
    "start": "node server.js",
    "test": "vitest --run"
  }
}

הרצת הפקודה npm test עם הקובץ הזה תפעיל את קבוצת הבדיקות של Vitest פעם אחת. ב-Vitest, ברירת המחדל היא לחפש את כל הקבצים שמסתיימים ב-'.test.js' או ב-דומה ולהריץ אותם. בהתאם להרצת הבדיקה שבחרתם, הפקודה עשויה להיות שונה מעט.

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

הפעלה ידנית של בדיקה

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

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

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

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

הפעלת בדיקות כחלק משליחה מראש או מבדיקה

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

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

לדוגמה, GitHub מתייחס אליהן כ "בדיקות סטטוס" שאפשר להוסיף באמצעות פעולות GitHub. פעולות GitHub הן למעשה סוג של בדיקה: כל שלב חייב להצליח (לא להיכשל או לגרום ל-Error) כדי שהפעולה תעבור. ניתן לך להחיל Actions על כל יחסי ה-PR של פרויקט, ופרויקט יכול לדרוש העברה של הפעולות לפני שמוסיפים קוד. פעולת ברירת המחדל של Node.js ב-GitHub מריצה את npm test כאחד מהשלבים שלה.

מטרת הבדיקה היא לוודא שה-codebase תמיד 'ירוק', על ידי אי קבלת קוד שלא מריץ את הבדיקות בהצלחה.

הרצת בדיקות כחלק מאינטגרציה רציפה (CI)

אחרי אישור ה-PR הירוק, רוב ה-codebase מריצים בדיקות שוב על סמך ההסתעפות main של הפרויקט, במקום ה-PR הקודם. העדכון עשוי להתבצע באופן מיידי או על בסיס קבוע (למשל, מדי שעה או לילה). התוצאות האלה מוצגות לעיתים קרובות כחלק מלוח בקרה של אינטגרציה רציפה (CI) שמראה את התקינות הכוללת של הפרויקט.

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

• כמה שינויים אושרו "בו-זמנית", שנקראים לפעמים תנאי מרוץ, והם משפיעים זה על זה בדרכים עדינות שלא נבדקו.
• לא ניתן לשחזר את הבדיקות, או שהן בודקות קוד "רעוע" – הן יכולות גם לעבור וגם להיכשל בלי לשנות את הקוד.
  • מצב זה עשוי להתרחש אם אתם תלויים במערכות חיצוניות ל-codebase שלכם. בשרת proxy, נניח שבודקים אם Math.random() > 0.05 – הפעולה הזו תיכשל באופן אקראי 5% מהזמן.
• חלק מהבדיקות יקרות מדי או יקרות מדי להפעלה בכל יחסי ציבור, כמו בדיקות מקצה לקצה (מידע נוסף על כך בסוגי בדיקות אוטומטיות), והן יכולות להפסיק לפעול עם הזמן בלי להתריע בכל פעם מחדש.

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

משחק אינטרוולים ב"גלגול"

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

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

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

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

משאבים

• למה כדאי ליצור גרסאות בלילה?

בחינת ההבנה