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

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

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

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

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

הרצת בדיקות ב-Headless Chrome

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

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

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

בדיקת דפים של תוספים

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

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

בספריות מסוימות, אפשר לפתוח את החלון הקופץ באמצעות ה-API‏ action.openPopup() ואז לקבל הפניה להקשר החדש. לדוגמה, ב-Puppeteer יש הסבר איך עושים את זה במדריך לתוספים ל-Chrome.

אם אי אפשר לעשות את זה בספרייה שבחרתם, פותחים את כתובת ה-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 await chrome.tabs.get(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)

במאמר בדיקת סיום של Service Worker באמצעות Puppeteer מוסבר איך לבדוק את סיום הפעולה של Service Worker. יש לנו גם דוגמה ל-Puppeteer ול-Selenium.

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