Tester une application Electron de bout en bout : au-delà de la prise en charge d'Electron par Playwright
Tester une application Electron telle que l'utilisateur la voit : ce que couvre l'API Electron de Playwright, où elle s'arrête, et un seul test à travers la page, la boîte de dialogue de fichier et la notification.
10 min de lecturePar Ait Nohaila, Chargée de développement commercial
La réponse courte
Pour tester une application Electron automatiquement, pilotez-la comme un utilisateur, boîtes de dialogue natives comprises, et vérifiez ce qu'elle dessine à l'écran.
- L'API Electron de Playwright couvre le renderer et le processus principal ; la coque native demande un outil qui voit l'écran.
Ce guide s'adresse aux développeurs et aux testeurs d'une application de bureau Electron.Il explique ce qui rend une telle application différente à tester, présente honnêtement l'API Electron de Playwright, puis montre un test de bout en bout à travers la page, la boîte de dialogue de fichier native, un export et sa notification, exécuté à chaque build.
Ce qui rend une application Electron différente à tester
Une application Electron, ce sont deux programmes qui travaillent ensemble.Le processus principal tourne dans Node.js : il ouvre les fenêtres, possède le cycle de vie de l'application, et demande au système d'exploitation tout ce qui est natif, comme les menus, les boîtes de dialogue et les icônes de la barre d'état.Chaque fenêtre fait ensuite tourner un processus de rendu, le renderer, qui est une page Chromium : HTML, CSS et JavaScript, comme un site web.
Pour les tests, cette séparation compte.Un outil conçu pour les sites web voit la page et seulement la page.Un utilisateur voit le tout : la barre de menus, la boîte de dialogue de fichier Windows qui s'ouvre sur Ouvrir, le message qui dit que l'export est terminé, l'icône qui reste dans la barre d'état une fois la fenêtre fermée.
C'est là que les applications Electron cassent d'une façon qu'un test au niveau de la page ne voit jamais.
- La boîte de dialogue Enregistrer sous s'ouvre sur le mauvais dossier.
- Une entrée de menu est grisée après une mise à jour.
- Une seconde fenêtre s'ouvre derrière la première.
- Une notification part deux fois, ou jamais.
- Des libellés passent à la ligne sur un portable de 1366 pixels.
Ce que couvre l'API Electron de Playwright, et où elle s'arrête
Parmi les outils de test d'interface pour Electron, Playwright est celui que la plupart des équipes essaient en premier, parce qu'elles l'utilisent déjà pour leur application web.Sa classe Electron est documentée comme une prise en charge expérimentale, pour Electron 21 et les versions suivantes.Le test lance l'application depuis son script d'entrée, obtient chaque fenêtre comme une page Playwright, et exécute du code dans le processus principal avec evaluate().
C'est une vraie prise sur l'application.Chaque localisateur, clic et assertion que Playwright offre sur une page web fonctionne sur le renderer, une seconde fenêtre arrive par l'événement window, et evaluate() peut lire ou changer l'état de l'application.Voir la classe ElectronApplication pour la liste complète.
La limite est documentée tout aussi clairement.Les appels de boîtes de dialogue natives comme dialog.showOpenDialog ne sont pas interceptés, parce qu'ils vont droit au système d'exploitation, et la documentation conseille de remplacer ces méthodes depuis le test par un simulacre qui renvoie le chemin de fichier voulu.La vraie boîte de dialogue ne s'ouvre jamais, donc elle n'est jamais testée.Il en va de même pour tout ce que le système d'exploitation dessine en dehors de la page.
| Ce que vous testez | L'API Electron de Playwright | Un test de l'écran, dans GUI Test Studio |
|---|---|---|
| La page (le renderer) | Chaque fenêtre est une page : localisateurs, clics, saisie, assertions, captures d'écran. | Des clics et des touches comme de vraies entrées, et des assertions sur ce que la page dessine. |
| Le processus principal | evaluate() y exécute votre code : lire l'état de l'application, simuler une méthode. | Pas atteint directement.Ce qu'il fait est vérifié là où cela se voit : à l'écran. |
| Boîtes de dialogue de fichier et de message natives | Pas interceptées, d'après sa propre documentation : le test remplace l'appel de la boîte de dialogue par un simulacre. | La vraie boîte de dialogue Windows fait partie du test : enregistrée, pilotée, vérifiée. |
| La barre d'état et les menus natifs | Pas d'appel dédié.Le gestionnaire d'une entrée de menu peut être exécuté depuis evaluate(), sans le clic. | Cliqués là où ils sont dessinés, à vue, comme l'utilisateur clique dessus. |
| Notifications du système | Aucun appel ne lit ce que Windows a dessiné.Le test peut vérifier le code qui en a demandé une. | Une assertion de texte attend les mots de la notification à l'écran. |
| Une seconde fenêtre | Chaque fenêtre est une page, par l'événement window ou par windows(). | N'importe quelle fenêtre à l'écran, la boîte de dialogue par-dessus comprise. |
| Ce que voit l'utilisateur | Une capture d'écran de la page d'une fenêtre, que le test peut comparer avec une capture stockée. | L'écran entier est enregistré, et chaque assertion compare ce qui est dessiné. |
Faits lus dans la documentation de Playwright le 6 novembre 2026.Playwright et Electron sont des marques de leurs propriétaires respectifs ; ce guide n'est ni affilié à eux ni approuvé par eux.
Une boîte de dialogue simulée prouve que l'application gère un chemin de fichier.Seule la vraie boîte de dialogue prouve que l'utilisateur peut choisir le fichier.
Un test de bout en bout à travers le renderer et la coque native
Voici comment tester une application Electron de bout en bout dans GUI Test Studio, avec une application de facturation comme exemple : ouvrir un fichier par la boîte de dialogue native, modifier une ligne, exporter un PDF, et vérifier la notification qui dit que c'est fait.
- 1
Enregistrer l'application, pas la page
Dans GUI Test Runner-Recorder, cliquez sur Enregistrer et choisissez Une application.Choisissez votre application Electron, ou parcourez jusqu'à son exécutable, et cochez la case qui la lance avec le test et la ferme à la fin, pour que chaque exécution commence avec une application fraîche.Puis utilisez-la comme le ferait un utilisateur.
L'écran entier est toujours enregistré.Le choix de l'application décide seulement d'où viennent les assertions automatiques. - 2
Ouvrir un fichier par la vraie boîte de dialogue
Cliquez sur Ouvrir.Pour l'enregistrement, la boîte de dialogue de fichier Windows est une fenêtre comme les autres : saisissez le chemin du fichier dans le champ du nom de fichier et appuyez sur Entrée, et les deux sont enregistrés comme de vraies entrées.Une assertion sur la boîte de dialogue est enregistrée avant le clic, pour que l'exécution attende qu'elle soit vraiment ouverte.
Beaucoup d'applications Electron sont aussi servies comme une page web.Pour cette version des mêmes écrans, l'étape Téléverser un fichier remet le fichier à la page sans aucune boîte de dialogue.
- 3
Modifier, exporter, et lire la notification
Changez une quantité, cliquez sur Exporter.Quand la notification apparaît, laissez-la affichée un instant avant d'arrêter : l'enregistrement note ce qui est apparu, et le test en reçoit une assertion.
- 4
Dire ce que le test doit vérifier
Quand vous arrêtez, GUI Test Runner-Recorder demande ce que le test doit vérifier : les éléments sur lesquels vous avez cliqué, les textes, et ce qui est apparu à l'écran.Gardez les trois activés.Chaque étape est ensuite un bloc sur la chronologie dans GUI Test Studio, et rien n'y nomme un processus.
Un enregistrement, cinq moments, trois endroits
- Coque nativeLancer une applicationDémarre l'application à neuf
- PageClic sur OuvrirAssertion visuelle sur le bouton
- Boîte de dialogueSaisie du nom de fichier, EntréeAssertion de texte : la boîte de dialogue est ouverte
- PageModifier, puis ExporterAssertion de texte sur le total
- BureauLa notificationAssertion de texte : Export terminé
Les assertions qui comptent : texte, visuel, disposition
Un enregistrement donne au test les assertions qui visent ses clics.Celles qui valent la peine d'être ajoutées à la main attrapent ce qu'une application Electron casse le plus souvent.
Assertion de texte
Une assertion de texte attend des mots : le titre de la boîte de dialogue, le total après la modification, Export terminé dans la notification, et une assertion de texte dynamique accepte une valeur d'un format connu, comme la date du jour dans un nom de fichier.
Assertion visuelle
Une assertion visuelle compare une image : le bouton Exporter, l'icône dans la barre d'état, l'entrée de menu qui ne doit pas être grisée.
Assertion de disposition
Une assertion de disposition vérifie que les éléments d'un écran sont toujours là où ils doivent être, ce qui attrape une fenêtre ouverte derrière une autre ou un libellé passé à la ligne sur un écran plus petit.
Chaque comparaison ignore le bruit de rendu que deux exécutions ont toujours, une nuance plus claire ici, un bord plus doux là, et attrape quand même les vraies régressions qu'une personne appellerait un changement : une icône manquante, un mot changé, un bouton de la mauvaise couleur.Voir Assertions visuelles pour la rigueur de chaque assertion.
Deux habitudes font tenir un test Electron.
- Vérifiez le résultat, pas seulement les clics : le total à l'écran, les mots de la notification.
- Donnez aux pièces natives leur propre assertion : le titre de la boîte de dialogue avant d'y saisir, l'entrée de menu avant de cliquer dessus.
Le rapport de confiance dit ensuite, pour chaque assertion, si l'élément a été trouvé et s'il a l'apparence enregistrée, avec l'image attendue et l'image trouvée côte à côte.Pour une application de bureau dont Windows ne peut pas décrire les contrôles, la même approche fonctionne à vue seulement : voir tester des applications Windows sans arbre d'accessibilité.
Les tests automatisés d'une application Electron à chaque build
gtr-cli, l'exécuteur en ligne de commande, exécute le test exactement comme le bouton Exécuter le test, et ajoute ce dont un pipeline a besoin : un code de sortie, un fichier JUnit, et chaque preuve d'un échec dans un seul dossier.
gtr-cli run tests\electron --countdown 0 --junit results\junit.xml --artifacts results\artifactsL'étape Lancer une application au début du test lance le build à tester : pointez-la vers l'exécutable empaqueté produit par le build, et le même test vérifie chaque version que vous livrez.L'agent de build a besoin d'une session de bureau Windows ouverte et déverrouillée, parce que l'application dessine sur un vrai écran.Le guide CI/CD la configure pour TeamCity, Jenkins, GitHub Actions, GitLab et Azure DevOps.
Une chose ne s'applique pas ici.Les navigateurs et appareils de GUI Test Studio créent des versions d'un test web pour Chrome, Edge, Firefox et des téléphones émulés, comme l'explique le test multi-navigateurs.Une application Electron embarque son propre Chromium, donc il n'y a qu'un navigateur à tester, et les versions qui comptent sont vos builds.
Le build s'exécute
gtr-cli lance l'application empaquetée
Le parcours est rejoué
Page, boîte de dialogue, export, notification
Rapport de confiance
Régression ou bruit, avec images
Livrer, ou corriger d'abord
Une assertion échouée fait échouer le build
Quand l'API Electron de Playwright reste le bon outil
Un guide honnête dit où l'autre outil gagne, et ici il gagne.L'API Electron de Playwright est le bon choix pour des tests au niveau du code du processus principal : evaluate() lit l'état de l'application directement, une boîte de dialogue simulée rend un test de la gestion des fichiers rapide et exact, et rien de tout cela n'a besoin d'un écran.Une équipe qui écrit déjà des tests Playwright pour son application web garde ses localisateurs et ses habitudes dans le renderer, et exécute ces tests en quelques secondes à chaque pull request.
Les deux ne sont pas rivaux.Gardez Playwright pour le renderer et le processus principal, et un test de l'écran pour le parcours qu'un utilisateur fait à travers la coque native : la vraie boîte de dialogue, le vrai menu, la vraie notification, sur le vrai build.Chacun attrape ce que l'autre ne peut pas voir.
Points clés
- 1Une application Electron, c'est une page plus une coque native : le processus principal possède les boîtes de dialogue, les menus, la barre d'état et les notifications, et un utilisateur les rencontre tous.
- 2L'API Electron de Playwright atteint la page et le processus principal depuis du code, et sa propre documentation dit que les boîtes de dialogue natives ne sont pas interceptées.
- 3GUI Test Studio teste l'application telle que l'utilisateur la voit : l'écran entier enregistré, la vraie boîte de dialogue de fichier pilotée comme n'importe quelle fenêtre, pas de build de test et pas de plugin.
- 4Les assertions de texte, visuelles et de disposition attrapent ce qui casse : un total faux, une icône manquante, une entrée de menu grisée, une fenêtre derrière une autre.
- 5Le même test s'exécute à chaque build avec gtr-cli, avec un fichier JUnit pour le pipeline ; les navigateurs et appareils sont pour les pages web, ici les versions sont vos builds.
Questions
Comment tester une application Electron automatiquement ?
Pilotez-la comme le fait un utilisateur : lancez l'application, cliquez et saisissez dans ses fenêtres, ouvrez ses boîtes de dialogue natives, et vérifiez ce qui est dessiné à l'écran.GUI Test Studio enregistre ce parcours une fois et le rejoue à chaque build, sans code de test.L'API Electron de Playwright est la voie d'accès depuis du code, pour la page et le processus principal.
Playwright prend-il en charge Electron ?
Oui, comme fonctionnalité expérimentale.La classe Electron de Playwright lance une application Electron depuis du code, vous donne chacune de ses fenêtres comme une page, et exécute du code dans le processus principal.Sa documentation cite Electron version 21 et les versions suivantes.
Playwright peut-il tester les boîtes de dialogue natives d'une application Electron ?
Pas telles que l'utilisateur les voit.La documentation de Playwright dit qu'il n'intercepte pas les appels de boîtes de dialogue natives comme dialog.showOpenDialog, et recommande de remplacer ces méthodes depuis le test.Un test qui doit ouvrir la vraie boîte de dialogue de fichier a besoin d'un outil qui pilote l'écran.
Comment tester les boîtes de dialogue d'ouverture et d'enregistrement de fichier d'une application Electron ?
Enregistrez-les.Dans GUI Test Studio, la boîte de dialogue de fichier Windows est une fenêtre comme les autres : le clic sur Ouvrir, le nom de fichier saisi et la touche Entrée sont enregistrés et rejoués comme de vraies entrées, et une assertion avant le clic s'assure que la boîte de dialogue est là.Quand les mêmes écrans sont servis comme une page web, l'étape Téléverser un fichier remet le fichier sans aucune boîte de dialogue.
Peut-on tester la barre d'état et les notifications d'une application Electron ?
Oui, quand le test voit l'écran.Une icône de la barre d'état et une notification sont dessinées par Windows en dehors de la fenêtre de l'application, si bien qu'un test qui n'atteint que la page ne peut pas les voir.GUI Test Studio enregistre l'écran entier : un clic sur l'icône de la barre d'état est un clic, et une assertion de texte attend les mots de la notification.
GUI Test Studio a-t-il besoin d'un build de test ou d'un plugin dans l'application Electron ?
Non.Rien n'est ajouté à l'application : GUI Test Studio regarde l'écran, utilise la souris et le clavier comme une personne, et demande à Windows ce que l'application décrit déjà.Le build que vous testez est le build que vous livrez.
Les tests d'une application Electron peuvent-ils tourner dans un pipeline CI/CD ?
Oui. gtr-cli exécute le même test sur un agent de build Windows avec une session de bureau déverrouillée, fait échouer le build quand une assertion échoue, et écrit un fichier JUnit pour l'onglet des tests de TeamCity, Jenkins, GitHub Actions, GitLab ou Azure DevOps.
Dois-je utiliser Playwright ou GUI Test Studio pour mon application Electron ?
Utilisez l'API Electron de Playwright pour des tests rapides, au niveau du code, de la page et du processus principal, surtout si votre équipe écrit déjà des tests Playwright.Utilisez GUI Test Studio pour le parcours de bout en bout tel que l'utilisateur le voit, boîtes de dialogue natives, barre d'état et notifications comprises, sans code de test.Les deux peuvent coexister.
Electron, Playwright, Chromium, Node.js, Windows, TeamCity, Jenkins, GitHub, GitLab et Azure DevOps sont des marques de leurs propriétaires respectifs.
Prêt à enregistrer votre premier test ?
Toutes les fonctionnalités, pendant 15 jours.
Vous préférez le voir sur le type d'application que vous testez ?Réservez un appel gratuit de 30 minutes avec notre équipe.