Electron App Testing End to End: Beyond Playwright's Electron Support

This guide is for the developers and QA people of an Electron desktop app.It says what makes such an app different to test, gives a fair account of Playwright's Electron API, then shows one end-to-end test through the page, the native file dialog, an export and its notification, run on every build.

What makes an Electron app different to test

An Electron app is two programs working together.The main process runs in Node.js: it opens the windows, owns the app's life cycle, and asks the operating system for everything native, such as menus, dialogs and tray icons.Each window then runs a renderer process, which is a Chromium page: HTML, CSS and JavaScript, like a website.

For testing, this split matters.A tool made for websites sees the page and only the page.A user sees the whole thing: the menu bar, the Windows file dialog that opens on Open, the toast that says the export is finished, the icon that lives on in the tray after the window is closed.

What Playwright's Electron API covers, and where it stops

Among Electron UI testing tools, Playwright is the one most teams try first, because they already use it for their web app.Its Electron class is documented as experimental support, for Electron 21 and later.The test launches the app from its entry script, gets each window as a Playwright page, and runs code in the main process with evaluate().

That is a real reach into the app.Every locator, click and assertion Playwright offers on a web page works on the renderer, a second window arrives through the window event, and evaluate() can read or change the app's state.See the ElectronApplication class for the full list.

The stop is just as clearly documented.Native dialog calls such as dialog.showOpenDialog are not intercepted, because they go straight to the operating system, and the documentation advises replacing those methods from the test with a stub that returns the file path you want.The real dialog never opens, so it is never tested.The same holds for everything else the operating system draws outside the page.

Facts read on Playwright's documentation on 6 November 2026.Playwright and Electron are trademarks of their respective owners; this guide is not affiliated with or endorsed by them.

One end-to-end test across the renderer and the shell

Here is how to test an Electron app end to end in GUI Test Studio, with an invoicing app as the example: open a file through the native dialog, edit a line, export a PDF, and check the notification that says it is done.

1. 1

   Record the app, not the page

   In GUI Test Runner-Recorder, click Record and pick An app.Choose your Electron app, or browse to its executable, and tick the box that starts it with the test and closes it at the end, so every run begins from a fresh app.Then use it as a user would.

   

   Enlarge

2. 2

   Open a file through the real dialog

   Click Open.The Windows file dialog is a window like any other to the recording: type the file's path into the file name field and press Enter, and both are recorded as real input.A check of the dialog is recorded before the click, so the run waits until it is really up.

   Many Electron apps are also served as a web page.For that version of the same screens, the Upload File step hands the file to the page without any dialog.

3. 3

   Edit, export, and read the toast

   Change a quantity, click Export.When the notification appears, let it stand a moment before you stop: the recording notes what appeared, and the test gets a check of it.

4. 4

   Say what the test must verify

   When you stop, GUI Test Runner-Recorder asks what the test should verify: the elements you clicked, the texts, and what appeared on the screen.Keep the three on.Every step is then a block on the timeline in GUI Test Studio, and nothing in it names a process.

The checks that matter: text, visual, layout

A recording gives the test the checks that aim its clicks.The ones worth adding by hand catch what an Electron app breaks most often.

Every comparison ignores the rendering noise two runs always have, a shade lighter here, a softer edge there, and still catches the real regressions a person would call a change: a missing icon, a changed word, a button in the wrong colour.See Visual checks for how strict each check is.

The Confidence Report then says, for every check, whether the element was found and whether it looks as recorded, with the expected and found pictures side by side.For a desktop app whose controls Windows cannot describe, the same approach works by sight alone: see testing Windows apps with no accessibility tree.

Electron automated testing on every build

gtr-cli, the command-line runner, runs the test exactly like the Run Test button, and adds what a pipeline needs: an exit code, a JUnit file, and every piece of evidence of a failure in one folder.

gtr-cli run tests\electron --countdown 0 --junit results\junit.xml --artifacts results\artifacts

The Run App step at the start of the test launches the build under test: point it at the packaged executable the build made, and the same test checks every version you ship.The build agent needs a signed-in, unlocked Windows desktop session, because the app draws on a real screen.The CI/CD guide sets it up for TeamCity, Jenkins, GitHub Actions, GitLab and Azure DevOps.

Enlarge

One thing does not apply here.GUI Test Studio's Browsers & Devices make versions of a web test for Chrome, Edge, Firefox and emulated phones, as cross-browser testing explains.An Electron app ships its own Chromium, so there is one browser to test, and the versions that matter are your builds.

When Playwright's Electron API is still the right tool

A fair guide says where the other tool wins, and here it does.Playwright's Electron API is the right choice for code-level tests of the main process: evaluate() reads the app's state directly, a stubbed dialog makes a test of the file handling fast and exact, and none of it needs a screen.A team that already writes Playwright tests for its web app keeps its locators and habits in the renderer, and runs those tests in seconds on every pull request.

The two are not rivals.Keep Playwright for the renderer and the main process, and a test of the screen for the journey a user takes through the shell: the real dialog, the real menu, the real notification, on the real build.Each catches what the other cannot see.

Key takeaways

• 1An Electron app is a page plus a shell: the main process owns the dialogs, menus, tray and notifications, and a user meets all of them.
• 2Playwright's Electron API reaches the page and the main process from code, and its own documentation says native dialogs are not intercepted.
• 3GUI Test Studio tests the app as the user sees it: the whole screen recorded, the real file dialog driven like any window, no test build and no plugin.
• 4Text, Visual and Layout Asserts catch what breaks: a wrong total, a missing icon, a greyed-out menu item, a window behind another.
• 5The same test runs on every build with gtr-cli, with a JUnit file for the pipeline; Browsers & Devices are for web pages, your builds are the versions here.

Questions

Electron, Playwright, Chromium, Node.js, Windows, TeamCity, Jenkins, GitHub, GitLab and Azure DevOps are trademarks of their respective owners.