Electron-Apps End-to-End testen: über die Electron-Unterstützung von Playwright hinaus
Electron-Apps so testen, wie der Nutzer sie sieht: was die Electron-API von Playwright abdeckt, wo sie aufhört, und ein einziger Test durch die Seite, den Dateidialog und die Toast-Benachrichtigung.
10 Min. LesezeitVon Ait Nohaila, Business Development Representative
Die kurze Antwort
Um eine Electron-App automatisch zu testen, bedienen Sie sie wie ein Nutzer, native Dialoge eingeschlossen, und prüfen Sie, was sie auf den Bildschirm zeichnet.
- Die Electron-API von Playwright deckt Renderer und Hauptprozess ab; die Shell braucht ein Werkzeug, das den Bildschirm sieht.
Dieser Leitfaden richtet sich an die Entwicklung und die QA einer Electron-Desktop-App.Er sagt, was eine solche App beim Testen anders macht, stellt die Electron-API von Playwright fair dar und zeigt dann einen End-to-End-Test durch die Seite, den nativen Dateidialog, einen Export und seine Benachrichtigung, ausgeführt bei jedem Build.
Was eine Electron-App beim Testen anders macht
Eine Electron-App besteht aus zwei Programmen, die zusammenarbeiten.Der Hauptprozess läuft in Node.js: Er öffnet die Fenster, steuert den Lebenszyklus der App und bittet das Betriebssystem um alles Native, etwa Menüs, Dialoge und Symbole im Infobereich.Jedes Fenster führt dann einen Renderer-Prozess aus, also eine Chromium-Seite: HTML, CSS und JavaScript, wie eine Website.
Für das Testen ist diese Aufteilung wichtig.Ein Werkzeug für Websites sieht die Seite und nur die Seite.Ein Nutzer sieht das Ganze: die Menüleiste, den Windows-Dateidialog, der sich bei „Öffnen“ öffnet, die Toast-Benachrichtigung, die sagt, dass der Export fertig ist, das Symbol, das nach dem Schließen des Fensters im Infobereich weiterlebt.
Genau dort gehen Electron-Apps auf eine Weise kaputt, die ein Test auf Seitenebene nie sieht.
- Der Speichern-Dialog öffnet sich im falschen Ordner.
- Ein Menüeintrag ist nach einem Update ausgegraut.
- Ein zweites Fenster öffnet sich hinter dem ersten.
- Eine Benachrichtigung erscheint zweimal, oder nie.
- Beschriftungen brechen auf einem Laptop mit 1366 Pixeln um.
Was die Electron-API von Playwright abdeckt und wo sie aufhört
Unter den Werkzeugen für UI-Tests von Electron ist Playwright dasjenige, das die meisten Teams zuerst ausprobieren, weil sie es schon für ihre Web-App nutzen.Seine Klasse Electron ist als experimentelle Unterstützung dokumentiert, für Electron 21 und neuer.Der Test startet die App über ihr Einstiegsskript, erhält jedes Fenster als Playwright-Seite und führt mit evaluate() Code im Hauptprozess aus.
Das ist ein echter Zugriff auf die App.Jeder Locator, jeder Klick und jede Assertion, die Playwright auf einer Webseite bietet, funktioniert im Renderer, ein zweites Fenster kommt über das Ereignis window an, und evaluate() kann den Zustand der App lesen oder ändern.Die vollständige Liste finden Sie in der Klasse ElectronApplication.
Die Grenze ist ebenso klar dokumentiert.Native Dialogaufrufe wie dialog.showOpenDialog werden nicht abgefangen, weil sie direkt an das Betriebssystem gehen, und die Dokumentation rät, diese Methoden im Test durch einen Stub zu ersetzen, der den gewünschten Dateipfad zurückgibt.Der echte Dialog öffnet sich nie, also wird er nie getestet.Dasselbe gilt für alles andere, was das Betriebssystem außerhalb der Seite zeichnet.
| Was Sie testen | Die Electron-API von Playwright | Ein Test des Bildschirms, in GUI Test Studio |
|---|---|---|
| Die Seite (der Renderer) | Jedes Fenster ist eine Seite: Locators, Klicks, Eingaben, Assertionen, Screenshots. | Klicks und Tasten als echte Eingabe, und Prüfungen dessen, was die Seite zeichnet. |
| Der Hauptprozess | evaluate() führt Ihren Code darin aus: den Zustand der App lesen, eine Methode durch einen Stub ersetzen. | Nicht direkt erreicht.Was er tut, wird dort geprüft, wo es sich zeigt: auf dem Bildschirm. |
| Native Datei- und Meldungsdialoge | Laut der eigenen Dokumentation nicht abgefangen: Der Test ersetzt den Dialogaufruf durch einen Stub. | Der echte Windows-Dialog ist Teil des Tests: aufgezeichnet, bedient, geprüft. |
| Der Infobereich und native Menüs | Kein eigener Aufruf.Der Handler eines Menüeintrags lässt sich über evaluate() ausführen, ohne den Klick. | Dort angeklickt, wo sie gezeichnet sind, am Aussehen, so wie der Nutzer sie anklickt. |
| Benachrichtigungen des Betriebssystems | Kein Aufruf liest, was Windows gezeichnet hat.Der Test kann den Code prüfen, der eine angefordert hat. | Eine Text-Assertion wartet auf die Wörter der Toast-Benachrichtigung auf dem Bildschirm. |
| Ein zweites Fenster | Jedes Fenster ist eine Seite, über das Ereignis window oder windows(). | Jedes Fenster auf dem Bildschirm, der Dialog darüber eingeschlossen. |
| Was der Nutzer sieht | Ein Screenshot der Seite eines Fensters, den der Test mit einem gespeicherten vergleichen kann. | Der ganze Bildschirm wird aufgezeichnet, und jede Prüfung vergleicht, was gezeichnet wird. |
Fakten laut der Dokumentation von Playwright, gelesen am 06.11.2026.Playwright und Electron sind Marken ihrer jeweiligen Inhaber; dieser Leitfaden steht in keiner Verbindung zu ihnen und wird nicht von ihnen unterstützt.
Ein Dialog als Stub beweist, dass die App einen Dateipfad verarbeitet.Nur der echte Dialog beweist, dass der Nutzer die Datei auswählen kann.
Ein End-to-End-Test über Renderer und Shell hinweg
So testen Sie eine Electron-App End-to-End in GUI Test Studio, mit einer Rechnungs-App als Beispiel: eine Datei über den nativen Dialog öffnen, eine Zeile bearbeiten, ein PDF exportieren und die Benachrichtigung prüfen, die sagt, dass es fertig ist.
- 1
Die App aufzeichnen, nicht die Seite
Klicken Sie im GUI Test Runner-Recorder auf Aufzeichnen und wählen Sie Eine App.Wählen Sie Ihre Electron-App oder suchen Sie ihre ausführbare Datei, und aktivieren Sie das Kontrollkästchen, das sie mit dem Test startet und am Ende schließt, damit jeder Lauf mit einer frisch gestarteten App beginnt.Benutzen Sie sie dann so, wie es ein Nutzer täte.
Es wird immer der ganze Bildschirm aufgezeichnet.Die Wahl der App entscheidet nur, woher die automatischen Prüfungen kommen. - 2
Eine Datei über den echten Dialog öffnen
Klicken Sie auf „Öffnen“.Für die Aufzeichnung ist der Windows-Dateidialog ein Fenster wie jedes andere: Geben Sie den Pfad der Datei in das Feld für den Dateinamen ein und drücken Sie die Eingabetaste, und beides wird als echte Eingabe aufgezeichnet.Vor dem Klick wird eine Prüfung des Dialogs aufgezeichnet, sodass der Lauf wartet, bis er wirklich offen ist.
Viele Electron-Apps gibt es auch als Webseite.Für diese Version derselben Bildschirme übergibt der Schritt Datei hochladen die Datei ohne jeden Dialog an die Seite.
- 3
Bearbeiten, exportieren und die Toast-Benachrichtigung lesen
Ändern Sie eine Menge, klicken Sie auf „Exportieren“.Wenn die Benachrichtigung erscheint, lassen Sie sie einen Moment stehen, bevor Sie stoppen: Die Aufzeichnung merkt sich, was erschienen ist, und der Test erhält eine Prüfung dafür.
- 4
Sagen, was der Test prüfen muss
Wenn Sie stoppen, fragt der GUI Test Runner-Recorder, was der Test prüfen soll: die Elemente, die Sie angeklickt haben, die Texte und das, was auf dem Bildschirm erschienen ist.Lassen Sie alle drei eingeschaltet.Jeder Schritt ist dann ein Block auf der Zeitleiste in GUI Test Studio, und nichts darin nennt einen Prozess.
Eine Aufzeichnung, fünf Momente, drei Orte
- ShellApp startenStartet eine frische App
- SeiteAuf „Öffnen“ klickenBild-Assertion auf der Schaltfläche
- DialogDateinamen eingeben, EingabetasteText-Assertion: Der Dialog ist offen
- SeiteBearbeiten, dann ExportierenText-Assertion auf die Summe
- DesktopDie BenachrichtigungText-Assertion: Export abgeschlossen
Die Prüfungen, auf die es ankommt: Text, Bild, Layout
Eine Aufzeichnung gibt dem Test die Prüfungen, die seine Klicks ausrichten.Die Prüfungen, die sich von Hand hinzuzufügen lohnen, fangen das, was bei einer Electron-App am häufigsten kaputtgeht.
Text-Assertion
Eine Text-Assertion wartet auf Wörter: den Titel des Dialogs, die Summe nach der Bearbeitung, „Export abgeschlossen“ in der Toast-Benachrichtigung, und eine Dynamische Text-Assertion akzeptiert einen Wert in einem bekannten Format, etwa das heutige Datum in einem Dateinamen.
Bild-Assertion
Eine Bild-Assertion vergleicht ein Bild: die Schaltfläche „Exportieren“, das Symbol im Infobereich, den Menüeintrag, der nicht ausgegraut sein darf.
Layout-Assertion
Eine Layout-Assertion prüft, dass die Elemente eines Bildschirms noch dort stehen, wo sie sollen, und fängt so ein Fenster, das sich hinter einem anderen geöffnet hat, oder eine Beschriftung, die auf einem kleineren Bildschirm umgebrochen ist.
Jeder Vergleich ignoriert das Rendering-Rauschen, das zwei Läufe immer haben, hier einen Hauch heller, dort eine weichere Kante, und fängt trotzdem die echten Regressionen, die ein Mensch eine Änderung nennen würde: ein fehlendes Symbol, ein geändertes Wort, eine Schaltfläche in der falschen Farbe.Wie streng jede Prüfung ist, erfahren Sie unter Bildprüfungen.
Zwei Gewohnheiten machen einen Electron-Test belastbar.
- Prüfen Sie das Ergebnis, nicht nur die Klicks: die Summe auf dem Bildschirm, die Wörter der Benachrichtigung.
- Geben Sie den nativen Teilen eine eigene Prüfung: den Titel des Dialogs, bevor Sie hineintippen, den Menüeintrag, bevor Sie ihn anklicken.
Der Konfidenzbericht sagt dann für jede Prüfung, ob das Element gefunden wurde und ob es so aussieht wie aufgezeichnet, mit dem erwarteten und dem gefundenen Bild nebeneinander.Für eine Desktop-App, deren Steuerelemente Windows nicht beschreiben kann, funktioniert derselbe Ansatz allein am Aussehen: siehe Windows-Apps ohne Barrierefreiheitsbaum testen.
Automatisierte Electron-Tests bei jedem Build
gtr-cli, der Befehlszeilen-Runner, führt den Test genau wie die Schaltfläche „Test ausführen“ aus und ergänzt, was eine Pipeline braucht: einen Exitcode, eine JUnit-Datei und jeden Nachweis eines Fehlschlags in einem Ordner.
gtr-cli run tests\electron --countdown 0 --junit results\junit.xml --artifacts results\artifactsDer Schritt „App starten“ am Anfang des Tests startet den zu testenden Build: Richten Sie ihn auf die gepackte ausführbare Datei, die der Build erzeugt hat, und derselbe Test prüft jede Version, die Sie ausliefern.Der Build-Agent braucht eine angemeldete, entsperrte Windows-Desktopsitzung, weil die App auf einen echten Bildschirm zeichnet.Der CI/CD-Leitfaden richtet das für TeamCity, Jenkins, GitHub Actions, GitLab und Azure DevOps ein.
Eines gilt hier nicht.„Browser und Geräte“ in GUI Test Studio erstellen Versionen eines Webtests für Chrome, Edge, Firefox und emulierte Smartphones, wie der Artikel Cross-Browser-Testing erklärt.Eine Electron-App bringt ihr eigenes Chromium mit, also gibt es einen einzigen Browser zu testen, und die Versionen, auf die es ankommt, sind Ihre Builds.
Der Build läuft
gtr-cli startet die gepackte App
Der Ablauf wird wiedergegeben
Seite, Dialog, Export, Toast-Benachrichtigung
Konfidenzbericht
Regression oder Rauschen, mit Bildern
Ausliefern oder zuerst beheben
Eine fehlgeschlagene Prüfung lässt den Build fehlschlagen
Wann die Electron-API von Playwright weiterhin das richtige Werkzeug ist
Ein fairer Leitfaden sagt, wo das andere Werkzeug gewinnt, und hier gewinnt es.Die Electron-API von Playwright ist die richtige Wahl für Tests des Hauptprozesses auf Code-Ebene: evaluate() liest den Zustand der App direkt, ein Dialog als Stub macht einen Test der Dateiverarbeitung schnell und genau, und nichts davon braucht einen Bildschirm.Ein Team, das schon Playwright-Tests für seine Web-App schreibt, behält seine Locators und Gewohnheiten im Renderer und führt diese Tests bei jedem Pull-Request in Sekunden aus.
Die beiden sind keine Rivalen.Behalten Sie Playwright für den Renderer und den Hauptprozess, und einen Test des Bildschirms für den Ablauf, den ein Nutzer durch die Shell nimmt: der echte Dialog, das echte Menü, die echte Benachrichtigung, auf dem echten Build.Jeder fängt, was der andere nicht sehen kann.
Das Wichtigste in Kürze
- 1Eine Electron-App ist eine Seite plus eine Shell: Dem Hauptprozess gehören die Dialoge, die Menüs, der Infobereich und die Benachrichtigungen, und ein Nutzer begegnet ihnen allen.
- 2Die Electron-API von Playwright erreicht die Seite und den Hauptprozess aus Code, und ihre eigene Dokumentation sagt, dass native Dialoge nicht abgefangen werden.
- 3GUI Test Studio testet die App so, wie der Nutzer sie sieht: der ganze Bildschirm aufgezeichnet, der echte Dateidialog wie jedes Fenster bedient, kein Test-Build und kein Plug-in.
- 4Text-, Bild- und Layout-Assertionen fangen, was kaputtgeht: eine falsche Summe, ein fehlendes Symbol, ein ausgegrauter Menüeintrag, ein Fenster hinter einem anderen.
- 5Derselbe Test läuft mit gtr-cli bei jedem Build, mit einer JUnit-Datei für die Pipeline; „Browser und Geräte“ sind für Webseiten da, hier sind Ihre Builds die Versionen.
Fragen
Wie testet man eine Electron-App automatisch?
Bedienen Sie sie so, wie es ein Nutzer tut: die App starten, in ihren Fenstern klicken und tippen, ihre nativen Dialoge öffnen und prüfen, was auf dem Bildschirm gezeichnet wird.GUI Test Studio zeichnet diesen Ablauf einmal auf und gibt ihn bei jedem Build wieder, ohne Testcode.Die Electron-API von Playwright ist der Zugang aus Code, für die Seite und den Hauptprozess.
Unterstützt Playwright Electron?
Ja, als experimentelle Funktion.Die Klasse Electron von Playwright startet eine Electron-App aus Code, gibt Ihnen jedes ihrer Fenster als Seite und führt Code im Hauptprozess aus.Ihre Dokumentation nennt Electron ab Version 21.
Kann Playwright native Dialoge in einer Electron-App testen?
Nicht so, wie der Nutzer sie sieht.Die Dokumentation von Playwright sagt, dass es native Dialogaufrufe wie dialog.showOpenDialog nicht abfängt, und empfiehlt, diese Methoden im Test zu ersetzen.Ein Test, der den echten Dateidialog öffnen muss, braucht ein Werkzeug, das den Bildschirm bedient.
Wie testet man die Dialoge zum Öffnen und Speichern von Dateien in einer Electron-App?
Zeichnen Sie sie auf.In GUI Test Studio ist der Windows-Dateidialog ein Fenster wie jedes andere: Der Klick auf „Öffnen“, der eingegebene Dateiname und die Eingabetaste werden als echte Eingabe aufgezeichnet und wiedergegeben, und eine Prüfung vor dem Klick stellt sicher, dass der Dialog da ist.Wenn dieselben Bildschirme als Webseite bereitgestellt werden, übergibt der Schritt „Datei hochladen“ die Datei ohne jeden Dialog.
Kann man den Infobereich und die Benachrichtigungen einer Electron-App testen?
Ja, wenn der Test den Bildschirm sieht.Ein Symbol im Infobereich und eine Benachrichtigung werden von Windows außerhalb des App-Fensters gezeichnet, sodass ein Test, der nur die Seite erreicht, sie nicht sehen kann.GUI Test Studio zeichnet den ganzen Bildschirm auf: Ein Klick auf das Symbol im Infobereich ist ein Klick, und eine Text-Assertion wartet auf die Wörter der Benachrichtigung.
Braucht GUI Test Studio einen Test-Build oder ein Plug-in in der Electron-App?
Nein.Der App wird nichts hinzugefügt: GUI Test Studio beobachtet den Bildschirm, benutzt Maus und Tastatur wie ein Mensch und fragt Windows, was die App bereits beschreibt.Der Build, den Sie testen, ist der Build, den Sie ausliefern.
Können Tests von Electron-Apps in einer CI/CD-Pipeline laufen?
Ja. gtr-cli führt denselben Test auf einem Windows-Build-Agent mit entsperrter Desktopsitzung aus, lässt den Build fehlschlagen, wenn eine Prüfung fehlschlägt, und schreibt eine JUnit-Datei für die Test-Registerkarte von TeamCity, Jenkins, GitHub Actions, GitLab oder Azure DevOps.
Sollte ich Playwright oder GUI Test Studio für meine Electron-App verwenden?
Verwenden Sie die Electron-API von Playwright für schnelle Tests der Seite und des Hauptprozesses auf Code-Ebene, besonders wenn Ihr Team schon Playwright-Tests schreibt.Verwenden Sie GUI Test Studio für den End-to-End-Ablauf, wie der Nutzer ihn sieht, native Dialoge, Infobereich und Benachrichtigungen eingeschlossen, ohne Testcode.Beide können nebeneinander bestehen.
Electron, Playwright, Chromium, Node.js, Windows, TeamCity, Jenkins, GitHub, GitLab und Azure DevOps sind Marken ihrer jeweiligen Inhaber.
Bereit, Ihren ersten Test aufzuzeichnen?
Jede Funktion, 15 Tage lang.
Lieber an der Art von App sehen, die Sie testen?Buchen Sie ein kostenloses 30-minütiges Gespräch mit unserem Team.