Motivation
The strongest differentiator of competing WPF automation MCP servers (e.g. WPF Buddy, WPF Pilot) is a QA/test story: record a workflow, replay it deterministically, and export a maintainable automated test. We have the widest interaction surface (click/set-text/select-item/send-keys/wait-for) and real visual-tree + binding inspection, but no record→export-test capability. Closing that gap makes us competitive on the terrain where the enterprise WPF audience actually is.
Proposal
Two new tools that reuse the existing interaction + query stack:
wpf_record — start/stop recording. While active, every state-changing tool call (click, set_text, select_item, send_keys) and each preceding find/wait_for used to locate the target is captured as an ordered step list, keyed by stable selectors (visible text, x:Name, AutomationId — not element handles, which are session-scoped).wpf_export_test — emit the recorded steps as runnable test code. First target: an xUnit test that drives the app through this project's own CLI/driver (self-contained, no extra dependency). Optionally a FlaUI variant later.
Design notes / open questions
- Selectors, not handles. Handles (
elem_XXXXXXXX) die with the session; exported tests must re-resolve elements by text/name/AutomationId + type. The recorder should snapshot the resolving criteria at capture time.
- Assertions. Offer a way to record an assertion step (e.g. "assert element with text X is visible", "assert TextBox Y has value Z") — maps naturally onto
wpf_wait_for + a value read.
- Waits. Insert
wpf_wait_for steps automatically after actions that trigger async work, or let the recorder capture explicit waits.
- Storage. Recording state lives server-side for the session;
wpf_export_test serializes it. Consider also a wpf_get_recording (raw JSON) for custom code-gen.
- Scope of v1. Linear happy-path recording + xUnit export is enough to ship; branching/loops/data-driven come later.
Acceptance
wpf_record start → drive the app with existing tools → wpf_record stop → wpf_export_test --format xunit produces a compiling test that reproduces the workflow against a fresh app instance.- Round-trip verified live against the sample app.
Tracked as "Next up" in the README roadmap.
Motivation
The strongest differentiator of competing WPF automation MCP servers (e.g. WPF Buddy, WPF Pilot) is a QA/test story: record a workflow, replay it deterministically, and export a maintainable automated test. We have the widest interaction surface (click/set-text/select-item/send-keys/wait-for) and real visual-tree + binding inspection, but no record→export-test capability. Closing that gap makes us competitive on the terrain where the enterprise WPF audience actually is.
Proposal
Two new tools that reuse the existing interaction + query stack:
wpf_record— start/stop recording. While active, every state-changing tool call (click,set_text,select_item,send_keys) and each precedingfind/wait_forused to locate the target is captured as an ordered step list, keyed by stable selectors (visible text, x:Name, AutomationId — not element handles, which are session-scoped).wpf_export_test— emit the recorded steps as runnable test code. First target: an xUnit test that drives the app through this project's own CLI/driver (self-contained, no extra dependency). Optionally a FlaUI variant later.Design notes / open questions
elem_XXXXXXXX) die with the session; exported tests must re-resolve elements by text/name/AutomationId + type. The recorder should snapshot the resolving criteria at capture time.wpf_wait_for+ a value read.wpf_wait_forsteps automatically after actions that trigger async work, or let the recorder capture explicit waits.wpf_export_testserializes it. Consider also awpf_get_recording(raw JSON) for custom code-gen.Acceptance
wpf_record start→ drive the app with existing tools →wpf_record stop→wpf_export_test --format xunitproduces a compiling test that reproduces the workflow against a fresh app instance.Tracked as "Next up" in the README roadmap.