Desktop app testing means installing the real build and using it the way a person would: launch, sign in, open a file, save, change settings. Browser tools cannot reach native windows, and desktop drivers take setup. From Claude Code, you can ask Sai to run those flows on a Windows or Linux cloud computer and send back failures with screenshots.
What desktop app testing covers
Desktop app testing checks a packaged application on a real operating system: that it installs, starts, accepts input, reads and writes files, keeps settings and closes cleanly. It covers the native parts of the app, such as menus, file dialogs and system prompts, that unit tests and web tests do not reach.
Many bugs only appear in the packaged build. The installer misses a file, a path differs on a clean machine, or a native dialog behaves differently than a mock.
Why automated desktop application testing is hard
- Browser tools stop at the window frame. Selenium drives browsers. Playwright has experimental support for Electron, but not for WPF, Qt or other native apps.
- Each framework needs its own driver. WinAppDriver and the Appium Windows driver cover UWP, WinForms, WPF and Win32 apps. pywinauto's UI Automation backend adds Qt5. Tauri has its own WebDriver setup.
- The driver itself needs care. The Appium Windows driver proxies to WinAppDriver, which its README says Microsoft has not maintained for years. Both need Windows 10 with Developer Mode on.
- Scripts depend on automation IDs. Controls without stable IDs or names make scripts brittle, and custom-drawn controls may expose none at all.
- Linux is a separate problem. pywinauto lists Linux support only as a long-term plan, so Windows scripts rarely carry over.
What to test in a desktop app before release
Use this list with any tool, scripted or not:
- Install and uninstall: on a clean machine, over an older version, and removal leaves no broken shortcuts.
- First launch: no error dialogs, the window opens at a sensible size, and first-run screens work.
- Sign-in: with a test account, including a wrong password and sign-out.
- Open and save: through the native file dialogs, with Save As, the right extension and an unsaved-changes prompt.
- Settings: changes survive a restart, including theme and language.
- Updates: the app updates from the previous release and keeps user data.
- Each target OS: at least one Windows and one Linux run if you ship both.
Desktop app testing tools, compared
| Approach | Setup | Frameworks | When the UI changes | Best for |
|---|---|---|---|---|
| Manual QA | A test machine and a person | Any | No change needed | Release checks on a small app |
| WinAppDriver or Appium Windows driver | Windows 10, Developer Mode, test code | UWP, WinForms, WPF, Win32 | Update locators | Existing Selenium-style suites on Windows |
| pywinauto | Python scripts on Windows | Win32 apps; WinForms, WPF and Qt5 through UI Automation | Update control lookups | Python teams automating Windows apps |
| Squish | Licensed tool, recorded or scripted tests | Qt, Java, Windows, macOS, web, Tk and more | Update the object map | Large Qt or multi-toolkit suites in CI |
| Playwright (Electron) or Tauri WebDriver | Test code against the app's web view | Electron (experimental) or Tauri | Update selectors | Fast checks of the web layer on every commit |
| Sai | A plain-English prompt | Any app a person can use on Windows or Linux | Works from what is on screen | Full flows on the packaged build, after agent-written changes |
If you need hundreds of fast, deterministic checks on every commit, a scripted suite with WinAppDriver, pywinauto or Squish is the better fit. Use Sai for full flows on the installed build and for the paths nobody has scripted yet.
How to test a desktop app from Claude Code with Sai
- Add the Sai MCP server. Add
@simular-ai/sai-mcpto Claude Code. Codex and Cursor work the same way. - Point to the build. Give a release or artifact link to the installer or package, and say Windows or Linux. The free plan includes one pooled Windows cloud computer; paid plans add dedicated Windows or Linux ones.
- List the flows. Launch, sign in, open, save, settings, or whatever matters for this change. The full prompt is in the Start with a prompt tab above.
- Watch and approve. Claude Code shows a
watch_urllink with the live screen and Sai's steps. Sign-ins and other sensitive steps wait for your approval there. - Close the loop. Claude Code reads the report, writes the fix, rebuilds, and asks Sai to run the failed flow again.
Sai ranks #1 on OSWorld, the public benchmark for agents that complete tasks on a real computer, including desktop apps. Once Sai completes a task, its steps are kept as code that replays the same way, so the next run of the same flows is faster and more consistent.
From your coding agent: the loop above runs inside Claude Code through the MCP server. From CI or your own scripts, call POST /v1/agents/message with the same prompt, or use the Python SDK (pip install sai-sdk, alpha). Read the quick start.
Tips for reliable desktop test runs
- Use a test account. Never a real customer or admin account. Sai gets the password through an approval link, not the chat.
- Ship a test file with the build. A known sample file makes open and save checks repeatable.
- Say what "pass" looks like. "The title bar shows the file name" is checkable; "it works" is not.
- Start clean. Ask Sai to remove older versions first, so you test a fresh install.
- Keep scope tight. Tell Sai not to change system settings outside the app.
Related use cases: test your signup flow end to end and reproduce a bug report step by step.
Last reviewed October 13, 2026.