Replacing a Test Framework with a Better Model

The team needed to run system-level tests against a WPF claims-management application. A separate group of about five developers had spent roughly two years building a framework that drove the running app and observed its UI, in a way that resembled a conventional automated-testing setup.

In practice it had real limitations: some UI interactions couldn't be automated reliably (a message box, for one, couldn't be interacted with at all), plus other compatibility problems. I was asked to look into it and try to get the existing approach working.

Rather than chasing the framework's limitations one by one, I stepped back from the assumption behind it. The instinct when you need to test something is to reach for a testing framework built for the job — but we already owned the application, its WPF components, and the API end to end, which opened up a different option.

I built a separate WPF application for system testing that directly hosted the component under test inside it. Since it was part of our own .NET codebase, I had direct access to its runtime behavior instead of treating it as a black box through an external tool.

To find any control I needed, I used attached properties that were already on the components (a leftover requirement from the original framework) and wrote a small helper that walked the component tree recursively until it found the target. That let the test app interact directly with buttons, dropdowns, and everything else, including message boxes, which the original framework couldn't touch at all.

The trade-off was giving up some of the conveniences of a conventional test setup in exchange for direct control over the component being tested. The original framework had assumed we needed an external test tool; the actual requirement was just to interact with the application reliably and check what it did.

I built the first version alone over about two weeks, demonstrated it to the team after the Christmas break, took feedback, and extended it from there.

It gave the team a level of direct control over the WPF application that the original two-year effort hadn't managed. The team lead was positive about it, and the developers behind the original framework wanted to discuss the approach — that conversation didn't happen before my engagement ended, so I can't say it formally replaced the original system.

What I can say is that a problem which had absorbed a lot of prior development time got a working alternative in about two weeks, simply by not taking the first answer — 'use a test framework' — for granted.