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

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

סקריפט נדרש

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

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

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

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

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

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

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

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

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

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

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

הרצת מבחנים במסגרת 'שליחה מראש' או 'בדיקה'

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

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

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

הגישה הזו לבדיקה מנסה לוודא שה-codebase שלכם תמיד "ירוק" על ידי אי-קבלת קוד שלא מריץ את הבדיקות שלו.

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

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

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

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

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

מרווח פנימי בנושא החזרה למצב קודם

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

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

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

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

משאבים

• מה היתרונות של גרסאות build ליליות

בדיקת ההבנה