I picked up the Figma workbench designs for Pidex and implemented the new-session, conversation, changes, history and models/access screens. Then I asked for unit, component and end-to-end UI coverage. The useful part was making the screens exercise the desktop app's actual boundaries.
The implemented Electron workbench during a UI test. The conversation, model selection and workspace contents are fixtures; the response comes from a scripted Pi peer, not a live model.
The Electron suite starts its own renderer on a free port and launches the app with temporary session storage, settings and a Git repository. A small executable stands in for Pi's RPC process. It returns models, streams a known response, handles Stop and can deliberately reject a prompt.1
That leaves a useful split:
| Boundary | What the tests exercise |
|---|---|
| Desktop integration | Actual Electron main process, preload bridge and renderer |
| Local state | Temporary session files, saved defaults and real Git staging |
| Model runtime | Scripted RPC responses, with no provider login or model call |
For Changes, clicking Stage file has to put exactly Composer.tsx in the repository's Git index. A changed button label alone would miss that. For history, previewing a saved conversation leaves the runtime-state request count unchanged; Resume then opens the conversation. A rejected prompt must put the typed text back in the composer so it can be retried.
The change is merged. Local validation passed 51 unit tests and 22 component tests, and CI passed all ten Electron UI tests. Those cover the screens, resume/fork, streaming/stop, staging, settings and the minimum desktop window size. Live provider authentication and responses still need their own check. Runtime-policy editing and automatic worktree creation remain unavailable in the UI.