Visuelles Testen von Electron-Apps: Web im Desktop-Shell, Bugs inklusive

Kernpunkte

Electron rendert Webinhalte in einem Desktop-Shell, was bedeutet, dass Ihre Anwendung alle visuellen Web-Bugs erbt — plus die Desktop-Besonderheiten
Variable Fenstergroessen, native Menues, Multi-Monitor-Unterstuetzung und Rendering-Unterschiede zwischen Betriebssystemen schaffen Bug-Kategorien, die es im klassischen Web nicht gibt
Eine Electron-App wie eine einfache Website zu testen ist ein Fehler: Der Desktop-Kontext veraendert die visuelle Erfahrung grundlegend
Automatisiertes visuelles Testen ist der einzige gangbare Ansatz, um die Kombinatorik OS x Aufloesung x DPI x Fenstergroesse abzudecken

Electron wird in seiner offiziellen Dokumentation als "ein Framework zur Erstellung nativer Desktop-Anwendungen mit Webtechnologien (HTML, CSS, JavaScript), das Chromium fuer das Rendering und Node.js fuer den Zugriff auf Systemfunktionen in einer einzigen plattformuebergreifenden Runtime kombiniert" definiert (Electron Documentation, electronjs.org).

Hinter dieser eleganten Definition verbirgt sich eine Realitaet, die jeder Electron-Entwickler kennt: Sie erhalten das Beste des Web (Oekosystem, Produktivitaet, reichhaltige UI-Komponenten) und das Schlechteste des Web (CSS-Inkonsistenzen, Renderingprobleme, variable Performance). Das Ganze, garniert mit einer zusaetzlichen Schicht Komplexitaet durch die Desktop-Umgebung.

Wenn Sie eine Electron-Anwendung entwickeln — und es ist sehr wahrscheinlich, dass Sie mehrere verwenden (VS Code, Slack, Discord, Figma, Notion, Obsidian) — wird Ihnen dieser Artikel zeigen, warum das visuelle Testen Ihrer Desktop-Anwendung besondere Aufmerksamkeit verdient und warum es nicht ausreicht, sie "wie Web" zu behandeln, obwohl es der richtige Ausgangspunkt bleibt.

Electron erbt alle visuellen Web-Probleme

CSS ist immer noch CSS

Ihre Electron-Anwendung verwendet dieselbe Rendering-Engine wie Chrome (Chromium, ueber das Electron-Projekt, das eine bestimmte Chromium-Version einbettet). Das bedeutet, dass alle visuellen Webprobleme gelten: CSS-Regressionen nach einem Abhaengigkeitsupdate, Textueberlaeufe, z-index-Probleme, falsch dimensionierte Bilder, ruckelnde Animationen, Schriften die nicht laden.

Wenn Sie bereits visuelles Testen fuer Web gemacht haben, kennen Sie diese Probleme. Und sie sind in Electron genauso praesent.

Aber hier ist die Falle: Viele Teams, die Electron-Anwendungen entwickeln, kommen nicht aus dem Web. Sie kommen vom nativen Desktop (C++, C#, Java Swing), wo CSS-Renderingprobleme nicht existieren. Sie entdecken diese Probleme zum ersten Mal, ohne die Erfahrung und die Tools, um damit umzugehen.

Chromium-Updates: das stille Risiko

Jedes Major-Update von Electron beinhaltet eine neue Chromium-Version. Und jede neue Chromium-Version kann das Rendering subtil veraendern. Eine Aenderung des Subpixel-Antialiasing, eine Aenderung in der Berechnung von Abrundungen, eine Entwicklung in der Schriftverwaltung — diese Aenderungen werden selten als Breaking Changes dokumentiert, aber sie koennen messbare visuelle Regressionen verursachen.

Das Electron-Team veroeffentlicht etwa alle acht Wochen eine neue Majorversion. Laut dem offiziellen Electron-Blog integriert jedes Major-Release eine Chromium-Version, eine Node.js-Version und eine V8-Version. Das sind viele potenzielle Aenderungsflaechen.

Wenn Sie nicht vor und nach jedem Electron-Update visuell testen, akzeptieren Sie ein stilles Regressionsrisiko fuer Ihre gesamte Oberflaeche.

Die Desktop-Besonderheiten, die alles aendern

Das veraenderbare Fenster: Responsive auf Steroiden

Im Web besteht Responsive Design darin, das Layout an einige vordefinierte Breakpoints anzupassen (Mobil, Tablet, Desktop). Die moeglichen Viewports sind zahlreich, aber durch die bestehenden Bildschirmgroessen begrenzt.

Auf dem Desktop kann das Fenster Ihrer Electron-Anwendung buchstaeblich jede Groesse annehmen, von 400 mal 300 Pixel bis 3840 mal 2160 Pixel, einschliesslich aller Zwischengroessen. Der Benutzer kann frei die Groesse aendern, und er tut es.

Das erzeugt ein kontinuierliches Spektrum moeglicher Layouts, nicht eine diskrete Menge von Breakpoints. Ihre Anwendung muss in jeder Groesse visuell korrekt sein — und die Zwischengroessen (zwischen Ihren Breakpoints) sind oft diejenigen, bei denen Probleme auftreten.

Einige typische Fehler beim Fenster-Resize:

Eine Sidebar, die sich ueber den Hauptinhalt legt, wenn das Fenster zu schmal fuer beides ist, aber zu breit, um den "collapsed"-Modus auszuloesen.

Eine Tabelle, die aus ihrem Container ueberlaeuft und ein unerwartetes horizontales Scrollen bei bestimmten Breiten erzeugt.

Action-Buttons in einem Header, die sich ueberlappen, wenn der horizontale Platz unzureichend ist, aber der mobile Breakpoint noch nicht erreicht wurde.

Ein schwebendes Panel (Inspector, Terminal, Befehlspalette), das aus dem sichtbaren Bereich herausragt, wenn das Fenster zu klein ist.

Native Menues: die Oberflaeche, die Sie nicht kontrollieren

Electron-Anwendungen koennen die nativen OS-Menues verwenden (Menuezeile auf macOS, Fenstermenue auf Windows und Linux). Diese Menues werden vom Betriebssystem gerendert, nicht von Ihrem CSS-Code. Ihr Erscheinungsbild variiert je nach OS, OS-Version und dem Systemtheme des Benutzers.

Visuell ist die Uebergangszone zwischen dem nativen Menue und Ihrem Webinhalt eine haeufige Problemquelle. Auf macOS werden die Titelleiste und das Menue vom System verwaltet. Auf Windows verwenden viele Electron-Anwendungen eine benutzerdefinierte Titelleiste (Frameless Window mit in CSS nachgebauten Steuerelementen) fuer einen moderneren Look.

Diese benutzerdefinierte Titelleiste ist eine visuell kritische Komponente. Die Schliessen-, Minimieren- und Maximieren-Buttons muessen an der richtigen Stelle, in der richtigen Groesse, in der richtigen Farbe sein und sich beim Hover korrekt verhalten. Und all das variiert zwischen den Plattformen: Auf macOS sind die Buttons links und rund; auf Windows sind sie rechts und eckig; auf Linux haengt es vom Window Manager ab.

Wenn Ihre Anwendung eine benutzerdefinierte Titelleiste verwendet, muss visuelles Testen sie auf jedem Ziel-OS abdecken. Es ist eine Komponente, die Benutzer staendig sehen und verwenden, und ein visueller Bug hier ist sofort wahrnehmbar.

Multi-Monitor und variables DPI

Die moderne Desktop-Umgebung besteht oft aus einem Laptop mit einem Retina-Display (2x DPI), verbunden mit einem externen Monitor in 1080p (1x DPI). Der Benutzer verschiebt Ihre Anwendung von einem Bildschirm zum anderen. Und wenn die Anwendung von einem 2x-Bildschirm zu einem 1x-Bildschirm wechselt, muss alles korrekt neu gerendert werden.

Visuelle Probleme im Zusammenhang mit DPI sind besonders tueckisch:

Bitmap-Bilder (PNG, JPG), die fuer ein einziges DPI erstellt wurden, erscheinen auf hochaufloesenden Bildschirmen unscharf oder auf niedrigaufloesenden Bildschirmen pixelig. Icons und Illustrationen muessen in mehreren Aufloesungen oder im Vektorformat (SVG) bereitgestellt werden.

1-Pixel-Raender werden in 1x und 2x nicht gleich angezeigt. Auf einem 2x-Bildschirm macht ein 1-Pixel-CSS-Rand 0,5 physische Pixel, was ihn je nach Rendering-Engine unsichtbar oder inkonsistent machen kann.

Schatten, Farbverlaeufe und Unschaerfeeffekte aendern subtil ihr Rendering zwischen den Aufloesungen. Was auf einem 1x-Bildschirm eine leichte Unschaerfe ist, wird auf einem 2x-Bildschirm eine ausgepraegt Unschaerfe, oder umgekehrt.

Texte unterliegen einem unterschiedlichen Antialiasing. Die Lesbarkeit einer duennen Schrift kann in 2x exzellent und in 1x maessig sein. Die typografische Wahl, die auf Ihrem Entwicklerbildschirm funktioniert (wahrscheinlich ein MacBook Retina), kann auf dem externen Monitor Ihres Benutzers katastrophal sein.

Taskleiste, Dock und System Tray

Ihre Anwendung interagiert mit der Desktop-Umgebung ueber das Taskleistensymbol (Windows/Linux), das Dock (macOS) und das System Tray. Diese winzigen Icons (16x16 bis 48x48 Pixel) muessen einwandfrei sein. Benachrichtigungsabzeichen, Statusoverlays, Kontextmenues — das sind visuelle Elemente, die Ihre Benutzer staendig sehen, auch wenn Ihre Anwendung nicht im Vordergrund ist.

Die drei Betriebssysteme: drei Renderings, drei Problemfelder

macOS: die anspruchsvolle Referenz

macOS ist oft die primaere Entwicklungsplattform. Die visuellen Besonderheiten umfassen die Ampel-Buttons (rot, gelb, gruen) links, das Schrift-Rendering durch Core Text (visuell "fetter" beim gleichen Gewicht als auf Windows) und die native Unterstuetzung des Dark Mode, der mit dem Theme Ihrer Anwendung harmonieren muss.

Windows: die Vielfalt der Konfigurationen

Windows bietet die groesste Vielfalt an Konfigurationen. Die Aufloesungen reichen von 1366x768 (laut StatCounter in 2025 noch 20 % der Bildschirme) bis 3840x2160. Die Skalierungsfaktoren (100 % bis 200 %) fuegen eine auf macOS nicht vorhandene Komplexitaet hinzu.

Das Schrift-Rendering durch DirectWrite erzeugt spuerbar andere Ergebnisse als Core Text: duennere, schaerfere Schriften, manchmal weniger lesbar in kleinen Groessen. Der "hoher Kontrast"-Modus fuer Barrierefreiheit kann das Erscheinungsbild Ihrer Anwendung drastisch veraendern, wenn Ihre CSS-Styles ihn nicht unterstuetzen.

Linux: der Sonderfall

Die Fragmentierung der Desktop-Umgebungen (GNOME, KDE, XFCE) macht die Standardisierung schwierig. Aber laut der Stack Overflow Developer Survey 2024 nutzen etwa 27 % der Entwickler Linux. Wenn Ihre Anwendung Entwickler anspricht, verdient Linux Abdeckung. Das Minimum: Ubuntu mit GNOME.

Visuelle Teststrategie fuer Electron

Ihre Testmatrix definieren

Der erste Schritt ist die explizite Definition der Kombinationen, die Sie testen werden. Mindestens sollte Ihre Matrix enthalten:

Die Ziel-Betriebssysteme. macOS (neueste und vorletzte Version), Windows 10, Windows 11. Linux Ubuntu LTS, wenn Ihre Zielgruppe es rechtfertigt.

Die priorisierten Bildschirmaufloesungen. Fuer jedes OS die zwei oder drei von Ihren Benutzern am haeufigsten verwendeten Aufloesungen. Auf macOS: 1440x900 und 2560x1600 (Retina). Auf Windows: 1920x1080 und 1366x768. Passen Sie anhand Ihrer tatsaechlichen Analytics-Daten an.

Die DPI-Faktoren. Mindestens 1x und 2x. Auf Windows fuegen Sie 1,5x (150 %) hinzu, eine sehr verbreitete Einstellung.

Die Fenstergroessen. Vollbild, halber Bildschirm (Split Screen) und eine reduzierte "minimal funktionale" Groesse. Diese drei Groessen decken die realen Nutzungsszenarien ab.

Erfassung auf mehreren OS automatisieren

Die technische Hauptherausforderung des visuellen Testens von Electron ist die Erfassung von Screenshots auf mehreren Betriebssystemen. Sie haben mehrere Optionen.

Der Multi-Plattform-CI-Ansatz. GitHub Actions, GitLab CI und Azure Pipelines unterstuetzen Jobs auf macOS, Windows und Linux. Konfigurieren Sie einen visuellen Test-Job pro OS, der Ihre App startet, zu den zu testenden Bildschirmen navigiert und Screenshots erfasst.

Der Playwright-Ansatz. Playwright unterstuetzt seit Version 1.20 nativ die Automatisierung von Electron: App-Start, Interaktionen, Screenshot-Erfassung, alles plattformuebergreifend.

Der Delta-QA-Ansatz. Fuer Teams, die keine Skripte pflegen wollen, bietet Delta-QA einen No-Code-Ansatz zur visuellen Erfassung und zum Vergleich der Bildschirme Ihrer Anwendung.

Die vorrangig zu ueberwachenden Bereiche

In einer Electron-Anwendung sind bestimmte Bereiche anfaelliger fuer visuelle Regressionen als andere. Konzentrieren Sie Ihre visuellen Tests auf diese Bereiche:

Die Titelleiste und Fenstersteuerung. Wenn Sie eine benutzerdefinierte Titelleiste verwenden (Frameless Window), testen Sie sie auf jedem OS. Die Schliessen-/Minimieren-/Maximieren-Buttons, der Drag-Bereich, der Anwendungstitel — alles muss pixelgenau und konform mit den Plattformkonventionen sein.

Veraenderbare Panels. Wenn Ihre Anwendung Panels (Sidebar, Bottom Panel, Inspector) hat, die der Benutzer in der Groesse aendern kann, testen Sie das Rendering in verschiedenen Panelgroessen. Die Resize-Handles, die Minimal- und Maximalgroessen, der sich anpassende Inhalt — alles muss visuell korrekt sein.

Kontextmenues. Native Kontextmenues haben auf jedem OS ein anderes Rendering. Benutzerdefinierte Kontextmenues (in CSS) muessen in Bezug auf Positionierung (nicht aus dem Fenster ueberquellen), Lesbarkeit und Konsistenz mit dem Anwendungstheme getestet werden.

Modale Dialoge. Systemdialoge (Datei oeffnen, speichern, drucken) sind nativ und erfordern kein visuelles Testen Ihrerseits. Aber die benutzerdefinierten Modals Ihrer Anwendung muessen getestet werden, insbesondere ihre Zentrierung, ihr Overlay und ihr Verhalten bei kleinem Fenster.

Ladezustaende und Uebergaenge. Der Start einer Electron-Anwendung kann einige Sekunden dauern. Was der Benutzer waehrend dieser Zeit sieht (Splash Screen, Ladebildschirm, leeres Fenster) ist Teil der Erfahrung und verdient einen visuellen Test.

Die haeufigsten Fehler

Nur auf einem OS testen

Das ist der haeufigste und teuerste Fehler. Wenn Ihr Team auf macOS entwickelt und auf macOS testet, gelangen Windows- und Linux-spezifische visuelle Bugs ungefiltert in die Produktion. Und Windows stellt in der Regel die Mehrheit Ihrer Electron-Benutzerbasis dar (laut Daten von Electron Fiddle und vielen populaeren Electron-Anwendungen macht Windows oft 60 bis 70 % der Installationen aus).

DPI-Faktoren ignorieren

Nur in 1x zu testen, wenn ein erheblicher Anteil Ihrer Benutzer in 2x ist (oder umgekehrt), ist ein Rezept fuer Ueberraschungen. DPI-Probleme sind subtil — leicht unscharfe Texte, verschwundene Raender, pixelige Icons — aber sie hinterlassen einen Eindruck von mangelnder Feinheit, der das Vertrauen untergräbt.

Electron wie einen Webbrowser behandeln

Ihre Electron-Anwendung ist kein Browser-Tab. Es ist eine Desktop-Anwendung, die der Benutzer installiert hat, die ihren eigenen Platz in der Taskleiste hat und nach den Standards nativer Anwendungen beurteilt wird. Benutzer tolerieren eine Website mit einem etwas kaputten Layout. Sie tolerieren keine installierte Desktop-Anwendung mit offensichtlichen visuellen Problemen.

Zwischen-Fenstergroessen vernachlaessigen

Wenn Sie nur im Vollbildmodus testen, verpassen Sie alle Bugs, die auftreten, wenn der Benutzer Ihre Anwendung im halben Bildschirm verwendet (Split Screen mit einer anderen Anwendung). Das ist ein extrem gaengiger Anwendungsfall auf dem Desktop, besonders fuer Produktivitaetstools.

FAQ

Electron verwendet Chromium, also reichen klassische Web-Tests, oder?

Nein. Electron verwendet Chromium fuer das Rendering, das stimmt. Aber die Umgebung ist grundlegend anders: unbegrenzt veraenderbares Fenster, keine Adressleiste, native OS-Menues, Taskleisten-Integration, Multi-Monitor-Unterstuetzung, variables DPI. Ihre klassischen Web-Tests decken das Chromium-Rendering in einem Browser ab. Sie decken nicht die Besonderheiten der Electron-Desktop-Umgebung ab. Beide Ebenen sind notwendig.

Wie geht man mit Schrift-Rendering-Unterschieden zwischen macOS und Windows um?

Das Schrift-Rendering unterscheidet sich strukturell zwischen Core Text (macOS) und DirectWrite (Windows). Der einzig zuverlaessige Weg, diese Unterschiede zu handhaben, ist die Pflege separater visueller Baselines pro OS. Vergleichen Sie keinen macOS-Screenshot mit einem Windows-Screenshot — sie werden immer unterschiedlich sein, und diese Unterschiede sind normal. Vergleichen Sie macOS mit macOS, Windows mit Windows.

Muss jedes Electron-Versionsupdate getestet werden?

Ja, und das ist nicht verhandelbar. Jedes Major-Update von Electron beinhaltet eine neue Chromium-Version, die das Rendering veraendern kann. Die Best Practice ist, Ihre vollstaendige visuelle Testsuite vor und nach dem Update durchzufuehren, die Ergebnisse zu vergleichen und die Unterschiede zu validieren. Einige Unterschiede werden Verbesserungen der Rendering-Engine sein (die Sie durch Aktualisierung der Baselines akzeptieren koennen), andere werden Regressionen sein (die Sie beheben oder melden muessen).

Wie testet man den Modus "Hoher Kontrast" von Windows?

Der Modus "Hoher Kontrast" (High Contrast Mode) von Windows ist eine Barrierefreiheitseinstellung, die die Farben Ihrer Anwendung durch ein Farbschema mit hohem Kontrast ersetzt. Sie koennen ihn programmatisch in Ihrer CI-Testumgebung aktivieren (ueber Systemeinstellungen oder Automatisierungstools). Erfassen Sie Screenshots in diesem Modus und pflegen Sie eine dedizierte Baseline. Das ist besonders wichtig, wenn Ihre Anwendung professionelle Umgebungen anspricht, in denen strenge Barrierefreiheitsrichtlinien gelten.

Meine Electron-App zielt nur auf macOS. Ist Multi-OS-Testing trotzdem notwendig?

Wenn Ihre Anwendung wirklich nur ein OS unterstuetzt, ist Multi-OS-Testing offensichtlich nicht notwendig. Aber ueberpruefen Sie diese Annahme: Viele "nur macOS"-Anwendungen stellen fest, dass ein Teil ihrer Benutzer die Anwendung unter Windows ueber inoffizielle Installationen oder Unternehmensanforderungen ausfuehrt. Wenn Sie zukuenftigen Windows-Support in Betracht ziehen, wird eine fruehe Investition in Multi-OS-Testing den Uebergang erheblich erleichtern.

Was ist die ideale Frequenz fuer visuelles Testen einer Electron-App?

Bei jedem Commit, der die Oberflaeche beruehrt, und bei jedem Electron-Versionsupdate oder UI-Abhaengigkeitsupdate. In der Praxis integrieren Sie visuelles Testen in Ihre CI/CD-Pipeline, damit es bei jedem Pull Request automatisch ausgefuehrt wird. Die Kosten eines gelegentlichen falsch-positiven Ergebnisses sind unendlich geringer als die Kosten einer an Tausende Desktop-Benutzer ausgelieferten visuellen Regression.

Weiterführende Lektüre

Electron gibt Ihnen die Macht, Desktop-Anwendungen mit Webtechnologien zu erstellen. Das ist eine Superkraft. Aber diese Superkraft bringt eine Verantwortung mit sich: Die visuellen Bugs des Web folgen Ihnen auf den Desktop, und sie werden von einer Kohorte desktop-spezifischer Probleme begleitet.

Die gute Nachricht ist: Wenn Sie bereits wissen, wie man Web visuell testet, haben Sie 80 % der notwendigen Faehigkeiten. Die restlichen 20 % — die Multi-OS-Matrix, die DPI-Faktoren, die veraenderbaren Fenster, die nativen Menues — sind eine natuerliche Erweiterung Ihres bestehenden Ansatzes.

Electron erbt alle Probleme des Web. Testen Sie es wie Web, dann gehen Sie weiter.

Delta-QA kostenlos testen →