בדיקה מקצה לקצה לתוספים ל-Chrome

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

במדריך בדיקת תוספים ל-Chrome באמצעות Puppeteer מוסבר איך כותבים בדיקות יחידה לתוספים ל-Chrome, ובמאמר בדיקת יחידה מוסבר איך כותבים בדיקות יחידה.

שימוש בספריות לבדיקת דפדפנים

תוספים נתמכים על ידי מגוון ספריות בדיקה.

הרצת בדיקות ב-Chrome ללא GUI

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

הגדרת מזהה תוסף

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

בדיקת דפי התוספים

אפשר לגשת לדפי תוספים באמצעות כתובת ה-URL התואמת שלהם, למשל chrome-extension://<id>/index.html. כדי לנווט לכתובות ה-URL האלה, משתמשים בשיטות הניווט הרגילות שזמינות בכלי האוטומציה שבחרתם.

בדיקת חלון קופץ של תוסף

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

const URL_PARAMS  = new URLSearchParams(window.location.search);

async function getActiveTab() {
  // Open popup.html?tab=5 to use tab ID 5, etc.
  if (URL_PARAMS.has("tab")) {
    return parseInt(URL_PARAMS.get("tab"));
  }

  const tabs = await chrome.tabs.query({
    active: true,
    currentWindow: true
  });

  return tabs[0];
}

מתבצעת בדיקה של מצב התוסף

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

ב-Puppeteer:

const workerTarget = await browser.waitForTarget(
  target => target.type() === 'service_worker'
);
const worker = await workerTarget.worker();

const value = await worker.evaluate(() => {
  chrome.storage.local.get('foo');
});

ב-Selenium:

// Selenium doesn't allow us to access the service worker, so we need to open an extension page where we can execute the code
await driver.get('chrome-extension://<id>/popup.html');
await driver.executeAsyncScript(
  'const callback = arguments[arguments.length - 1];' +
  'chrome.storage.local.get(\'foo\').then(callback);'
);

סיום של קובצי שירות (service worker)

למידע נוסף על בדיקת סיום של שירותי עובדים, ראו בדיקת סיום של שירותי עובדים באמצעות Puppeteer. יש לנו גם דוגמה ל-Puppeteer ול-Selenium.

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