Launch the Electron app with Playwright, test the sign-in interface when login itself is under test, and assert a visible authenticated result rather than relying on fixed delays. For other feature tests, prepare and reuse authentication state—but isolate Electron sessions, protect state files, and account for server-side effects when tests run in parallel.
What to know before automating Electron sign-in
Playwright describes its Electron automation support as experimental, so validate the approach with your app, Playwright and Electron versions, and CI environment. Its Electron API documentation lists support for Electron v12.2.0+, v13.4.0+, and v14+; that version-sensitive list is not a guarantee for every operating system, packaged app, or CI runner. See the Playwright Electron API documentation.
As an Amazon Associate I earn from qualifying purchases.
Electron automation gives a test access to the main process and Electron windows. That makes it possible to test a desktop sign-in flow, but it also means the app’s session, window behavior, and any native OS UI matter—not just the page’s form controls.
Recommended Free Tools
Launch the app and identify the login window
Use Playwright’s Electron API to start the application and obtain a window. The official example launches with _electron.launch({ args: ['main.js'] }), gets the first window with firstWindow(), interacts with it, then closes the application. Adapt the entry point and window selection to your app:
#1 Best Overall
const electronApp = await _electron.launch({ args: ['main.js'] });
const window = await electronApp.firstWindow();
// Interact with the app's login UI here.
await electronApp.close();If sign-in opens a separate window or redirects to another destination, identify and assert against that actual window or destination. A successful click or submit event alone does not establish that authentication completed.
Test the sign-in path with observable outcomes
When the test’s purpose is to verify login, exercise the actual interface: enter credentials, submit, and check the resulting behavior. Use selectors and expected text that match your application; the documentation does not define app-specific selectors, destination URLs, or error messages.
- Start from a deliberately signed-out session and confirm the login screen is present.
- Enter valid test credentials and submit the form.
- Wait for a meaningful outcome, such as the expected final URL or a visible signed-in control, then assert that outcome.
- For a rejected login, submit invalid credentials, assert the expected validation or authentication error, and verify protected content is still unavailable.
Playwright’s authentication guide demonstrates waiting for a final URL and also describes checking for a visible profile control. Prefer these observable conditions to a fixed sleep, which can be too short on a slow run and waste time on a fast one. See Playwright’s authentication guide.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Choose UI login or reusable authentication state
Keep login tests distinct from tests whose purpose is an authenticated feature. If a feature test does not need to verify the login interface, Playwright documents preparing authentication in a setup project and reusing the resulting state. Where the application offers a suitable authentication endpoint, API-based setup is another documented option. These approaches save repeated UI login work, but they do not test the sign-in interface in that feature test; retain UI coverage for the login behavior and redirects you need to protect.
| Approach | Best for | Main trade-off |
|---|---|---|
| UI sign-in | Testing authentication behavior and the user-facing login path | Exercises the UI, but repeats that work when used to prepare every feature test. |
| API or prepared-state setup | Preparing a signed-in context for a test focused on another feature | Can reduce repeated login work, but does not validate the login UI in that test. |
Playwright’s authentication guide also makes account reuse conditional on server-side effects. A shared account can work when concurrent tests do not change shared server-side state. If parallel tests mutate that state, use a different account per parallel worker to reduce interference.
Control Electron session persistence
Electron’s BrowserWindow can use a Session or a partition. A partition prefixed with persist: is persistent and shared by app pages using that partition; a partition without that prefix is in-memory. Choose deliberately: persistent storage can match app behavior that should survive launches, while an in-memory session helps prevent one test run’s cookies from making a later run appear already signed in.
Check which session the login window and the window under test actually use. If they do not share the intended session, a successful login in one window may not authenticate the other. Electron documents the session and partition behavior in its Session API and BrowserWindow API.
| Session choice | Best for | Main trade-off |
|---|---|---|
Persistent partition (persist:) |
App behavior that intentionally retains session data | Retains shared session state, so tests need deliberate cleanup or isolation. |
| In-memory partition | Temporary sessions and clean test isolation | Does not provide persistent session behavior across runs. |
Save the authentication data your app actually uses
Playwright storage state covers cookies and local storage and can include IndexedDB. If your app keeps authentication tokens in IndexedDB, use the documented IndexedDB option when saving state. Session storage is not persisted automatically; Playwright’s authentication guide provides a save-and-restore approach for it. These storage mechanisms are not interchangeable, so first identify where the app stores its authentication data.
Keep authentication state files in a gitignored directory. Playwright warns that such files can contain cookies and headers that enable impersonation. Refresh state when it expires, and use test output directories where appropriate for files that should be local to a run. See the authentication guide and storageState API documentation.
Stub native dialogs instead of depending on OS UI
Playwright cannot intercept Electron’s native dialog calls: they run in the main process and reach OS APIs. If a login flow triggers a file chooser or another native dialog, stub methods such as dialog.showOpenDialog through electronApp.evaluate() rather than making the test depend on operating-system UI. The Electron API documentation describes this approach.
Build a focused login test suite
- Successful login: use valid test credentials, wait for the expected destination or authenticated interface, and assert a stable signed-in marker.
- Rejected login: check the expected error and confirm protected content remains unavailable.
- Session reset: launch with a clean test session and prove the signed-out state before entering credentials.
- Authenticated feature: use prepared state when login is outside the test’s purpose.
- Parallel execution: use separate accounts when workers mutate shared server-side state.
- Redirect or secondary window: observe the relevant destination or window and assert its final state, not just that submission occurred.
The expected URLs, selectors, error text, and test account setup must come from the application being tested. The documented Playwright and Electron APIs provide the automation mechanisms; they do not establish the behavior of a particular app or backend.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
