How to test an Electron application, not just its web interface
An Electron application uses web technologies, but users launch it as a desktop program. A standard web page test may therefore verify a form or navigation, but it may not cover application startup, multiple windows, local files or updates. A reliable solution combines checks of the web and desktop layers.
The problem: testing in a browser alone is not enough
Electron has a renderer process for the user interface and a main process that manages windows and desktop functionality. If a test opens only a web address, it bypasses some of the code that customers use in the installed application.
Common problems occur in the following areas:
- the application fails to start after installation or loads the wrong configuration;
- the main and secondary windows do not share state correctly;
- opening a file, exporting or using a custom URL protocol works only in certain environments;
- the application fails to start with the original data after an update;
- an offline state or service outage leaves the interface without a clear response;
- a system dialog, menu or system tray icon behaves differently from the HTML part.
Not every Electron application uses all of these features. The test scope should be based on what your product actually does.
How to divide testing into layers
We verify web components and business logic with faster tests that do not launch the entire application. A smaller number of end-to-end scenarios then launch the packaged Electron application and check the user’s journey from startup to the result.
Playwright provides an interface for launching an Electron application and working with its windows and code in the main process. This support is still marked as experimental in the official documentation, so before a broader implementation, we verify compatibility with the specific Electron version and the way the application is built.
For system dialogs, we choose one of two approaches:
- for a logic test, we replace the dialog in a controlled way and return a known file path;
- for a genuine end-to-end scenario, we add a tool for controlling the native Windows interface.
Playwright does not intercept calls to Electron’s native dialogs because the main process sends them directly to the operating system. We therefore treat the installer, update and data migration as a separate layer; testing installation and updates describes the process in more detail.
We record video, screenshots, logs and traces as needed in the test configuration. They are not an automatic output of every run, and when sensitive data is involved, you need to determine what may be stored.
What to watch out for
An update test needs a controlled package source, clearly defined original and target versions, and safe test data. File system tests need an isolated working directory so that one run does not affect the next. At the same time, the CI runner must be able to launch a graphical application in a supported environment.
What you gain
The team verifies the application in the form delivered to the customer, not just its web components. This coverage can detect errors in startup, window handling and work with local files before release, while faster web tests continue to provide early feedback.
Results from the individual layers help narrow down whether the probable cause lies in the business logic, renderer layer or desktop integration.
Next step
List three features that distinguish your Electron application from its web version—for example, working with files, multiple windows and updates. Verify one of them in a pilot using an actual application build. If the product also includes a standalone website, compare the options with automated testing of web applications.