Back to Skills

windows-desktop-e2e

E2E testing for Windows native desktop apps (WPF, WinForms, Win32/MFC, Qt) using pywinauto and Windows UI Automation.

228,361stars35,033forksUpdated 7/11/2026

Security Assessment

Low Risk(80/100)

Detected risks:

Agent-reviewed override(subprocess.Popen launches ffmpeg (screen recording) and the app under test for Windows desktop E2E automation; .env is test config. Legitimate test-automation skill.)
Security Score80/100

About windows-desktop-e2e

End-to-end testing for Windows native desktop applications using pywinauto with the UIA (Windows UI Automation) backend, covering WPF, WinForms, Win32/MFC, and Qt (5.x and 6.x). All supported frameworks expose a tree of UIA elements — a built-in Windows accessibility API — whose properties tests can read and act on, with each framework shipping its own UIA provider. A reliability table rates automation quality by framework (WPF and Qt 6.x excellent, WinForms and Qt 5.15+ good, Win32/MFC and older Qt fair), noting mappings such as WPF x:Name to AutomationId and WinForms AccessibleName. Setup installs pywinauto with pytest, pytest-html, Pillow, and pytest-timeout on Windows with Python 3.8+, optionally ffmpeg for screen recording, and recommends Accessibility Insights for Windows for inspecting the UIA tree before writing tests. Its most emphasized practice is testability: giving every interactive control a stable AutomationId before writing tests, with per-framework instructions (WPF x:Name, WinForms AccessibleName, Win32/MFC resource IDs, and a dedicated Qt section). It lays out a Page Object Model project structure with conftest.py app-launch fixtures, config, page classes, and an artifacts directory, and provides a reusable BasePage with prioritized locators (AutomationId first, then name, then class plus index as a fragile fallback), waits (wait_visible, wait_gone, wait_window for new dialogs, and a generic polling wait_until for when UIA events are unreliable), actions (click, type_text with a keyboard fallback for incomplete Qt 5.x Value Pattern support, and get_text), and screenshot capture. Example LoginPage and conftest fixtures show the pattern in practice, including setting QT_ACCESSIBILITY. It clarifies when not to use it — web apps (use Playwright), Electron/CEF/WebView2, and mobile — and covers integrating desktop E2E into CI/CD on GitHub Actions windows-latest runners, plus diagnosing flaky automation.

FAQ

What tools does this rely on?

pywinauto driving the Windows UI Automation (UIA) backend, with pytest, pytest-html, Pillow, and pytest-timeout, on Windows with Python 3.8+; ffmpeg is optional for screen recording.

How should I locate controls reliably?

Prefer AutomationId (by_id) as the most stable locator, fall back to visible text or accessible name, and use class name plus index only as a last resort since it is fragile.

What is the single most impactful step before writing tests?

Give every interactive control a stable AutomationId — via x:Name in WPF, AccessibleName in WinForms, or resource IDs in Win32/MFC — so tests do not depend on brittle text or class matching.

When should I not use this skill?

For web apps use the e2e-testing (Playwright) skill instead; Electron, CEF, and WebView2 apps need browser automation for their HTML layer, and mobile apps need platform-specific tools like UIAutomator or XCUITest.

How does it handle Qt text-entry quirks?

The type_text action first tries set_edit_text and, if that fails (for example Qt 5.x's incomplete UIA Value Pattern), falls back to clicking the control and sending keyboard input, and it sets QT_ACCESSIBILITY=1 for older Qt.

Install windows-desktop-e2e

Download and extract the skill files to your .claude/skills/ directory.

Quick Setup:

  1. Copy the skill folder to .claude/skills/
  2. Claude will automatically detect and use the skill