Les tests de bout en bout impliquent la création et le chargement d'un package d'extension dans un navigateur. Un outil de test communique avec le navigateur pour automatiser les interactions et tester les mêmes flux qu'un utilisateur. Une bibliothèque compatible avec les tests de bout en bout fournit généralement des moyens de contrôler le navigateur, de simuler les entrées utilisateur et d'observer l'état actuel des pages ouvertes.
Consultez le tutoriel Tester des extensions Chrome avec Puppeteer, et les tests unitaires pour en savoir plus sur l'écriture de tests unitaires pour les extensions Chrome.
Utiliser des bibliothèques de test de navigateur
Les extensions sont compatibles avec un large éventail de bibliothèques de test.
Bibliothèque | Conseils |
---|---|
Puppeteer / Playwright | Consultez les extensions Chrome (Puppeteer / Playwright). |
Sélénium | Utilisez l'objet ChromeOptions pour charger des extensions. Pour en savoir plus, cliquez ici. |
WebDriverIO | Consultez Test des extensions Web. |
Exécuter des tests dans Headless Chrome
Lorsque vous exécutez des tests dans le cadre d'un workflow automatisé, il est souvent nécessaire de charger votre extension sur une machine qui ne dispose pas d'écran. Le nouveau mode headless de Chrome permet de l'exécuter dans un environnement sans surveillance tel que celui-ci. Lancez Chrome à l'aide de l'indicateur --headless=new
(actuellement sans interface graphique, la valeur par défaut est "old", qui n'est pas compatible avec le chargement des extensions). Selon l'outil d'automatisation que vous choisissez, il peut exister un paramètre qui ajoute automatiquement l'indicateur.
Définir un ID d'extension
Il est souvent souhaitable d'avoir un ID d'extension fixe dans les tests. Cela facilite de nombreuses tâches courantes, comme ajouter l'origine de l'extension à la liste d'autorisation sur un serveur avec lequel elle doit communiquer ou ouvrir des pages d'extension dans les tests. Pour ce faire, suivez les étapes décrites dans la section Maintenir un ID d'extension cohérent.
Tester les pages d'extension
Vous pouvez accéder aux pages des extensions à l'aide de leur URL correspondante, par exemple chrome-extension://<id>/index.html
. Pour accéder à ces URL, utilisez les méthodes de navigation standards disponibles dans l'outil d'automatisation de votre choix.
Tester une extension pop-up
Il n'est actuellement pas possible d'ouvrir une fenêtre pop-up d'extension dans le contexte d'une autre page. Ouvrez plutôt l'URL du pop-up dans un nouvel onglet. Si votre pop-up utilise l'onglet actif, envisagez d'implémenter un forçage permettant de transmettre explicitement un ID d'onglet à votre pop-up. Exemple :
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];
}
Inspecter l'état de l'extension
Pour éviter les échecs de test lorsque vous modifiez le comportement interne de votre extension, il est généralement recommandé d'éviter d'accéder à l'état interne dans un test d'intégration. Vous devez plutôt baser vos tests sur ce qui est visible par l'utilisateur. Toutefois, il peut parfois être souhaitable d'accéder directement aux données à partir de l'extension. Dans ce cas, envisagez d'exécuter du code dans le contexte d'une page d'extension.
Dans 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');
});
En sélénium:
// 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);'
);
Tester l'arrêt du service worker
Pour en savoir plus sur le test de l'arrêt du service worker, consultez la section Tester l'arrêt du service worker avec Puppeteer. Nous proposons également un exemple pour Puppeteer et Selenium.
Notez que lorsque vous utilisez certains frameworks de test, les services workers peuvent ne pas s'arrêter automatiquement comme ils le feraient en utilisation normale. C'est le cas chez Selenium. Il s'appuie sur ChromeDriver, qui associe un débogueur à tous les services workers pour les empêcher d'être arrêtés.