סביבת הבדיקה

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

אפשר להתייחס לסביבת הבדיקה כאל שני רכיבים: סביבת זמן הריצה שבה אתם משתמשים כדי להריץ את הבדיקה (למשל הצומת או הדפדפן) וממשקי ה-API שזמינים לכם.

סביבת זמן הריצה

זמני ריצה כמו Node או כלים דומים כמו Deno או Bun נועדו לתמוך בקוד JS בצד השרת או לשימוש כללי. הסביבות שלהם לא כוללות ממשקי API שאתם מצפים להם בדפדפן, כמו יצירה ועבודה עם רכיבי DOM ו-HTML, וגם לא תפיסה של רכיב חזותי או יעד עיבוד (כלומר, לא רק רכיבי רק, אלא עיבוד של הרכיבים האלה באופן חזותי עם CSS לנקודת מבט).

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

מצד שני, אם תריצו את הבדיקות בדפדפן, יכול להיות שממשקי API מובנים שאפשר לצפות להם מזמני הריצה לא יהיו זמינים בלי מילוי טופס מרובה או עבודה נוספת. קיצור דרך נפוץ הוא כמו קריאה וכתיבה של קבצים: פשוט לא ניתן import { fs } from 'node:'fs'; בתוך דפדפן ולקרוא קובץ בצורה הזו כחלק מבדיקה.

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

בדיקת היגיון אלגוריתמי או עסקי

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

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

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

אמולציה של ממשקי API לדפדפן

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

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

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

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

שליטה בדפדפן אמיתי

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

כשאתם שולטים בדפדפן כחלק מבדיקה, הוא נפתח בדיוק כמו שהוא נפתח אצל משתמש, והבדיקה יכולה לשלוט בו על ידי טעינת כתובות URL, HTML ו-JS בהתאמה אישית, או כל דבר אחר שנדרש כדי לבצע את הבדיקה. לאחר מכן תוכלו לכתוב קוד שיתפקד בתור משתמש, למשל על ידי שליטה בעכבר או הקלדת קלט בתיבות קלט.

כלים מודרניים כמו WebdriverIO או Web Test Runner יכולים לשלוט בכל הדפדפנים המובילים, ואפילו להריץ מספר מכונות בו-זמנית. הדפדפנים האלה יכולים לפעול בצמוד להרצת הבדיקה (לדוגמה, במחשב שלכם או כחלק מפעולת CI), או להשתמש במיקור חוץ לשירותים מסחריים חיצוניים שיפעילו אותם בשבילכם.

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

בפועל

ככל שמורכבות הבדיקות הולכת וגדלה, כך יותר ויותר חשוב להשתמש בדפדפן אמיתי.

  • לבדיקות שמשתמשות בתכונות ללא תכונות של ה-DOM או שהן מינימליות, אפילו תכונות שזמינות ב-Node.js ובזמני ריצה דומים, כמו fetch או EventTarget, לסביבה אין חשיבות.
  • JSDOM יכול להתאים לבדיקות של רכיבים קטנים.
  • בדיקות גדולות יותר, כמו בדיקות מקצה לקצה, שיכולות לדמות התחברות של משתמש וביצוע פעולה עיקרית, הן הגיוניות לפעול באופן מלא בדפדפן אמיתי.

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

בחינת ההבנה

באילו תכונות של הדפדפן שכבת האמולציה jsdom *לא* תומכת?

מנוע הפריסה.
JSDOM הוא לא כלי חזותי, ולכן לא ניתן להשתמש בו כדי לבדוק את המיקום של אלמנט בדף, את מאפייני ה-CSS המפוענחים שלו או כל חלק אחר בפריסה של אתר.
WebSocket
JSDOM כולל את ה-polyfill של WebSocket, כך שקוד שמשתמש בו יפעל.
requestAnimationFrame
עם הדגל 'pretendToBeVisual', jsdom יפעיל את הקריאה החוזרת 'animation' בקצב של 60fps, למרות ששום דבר לא משורטט בפועל.