UI Tests Without a UI Flow: Beware the Green Check

MSTest 4.5 and MTP 2.5 run WinUI 3 and UWP tests in the app's UI thread—learn why STA is not enough.

  • What happened
  • What Microsoft reported
  • Why an STA thread is not enough
  • What This Means for Business

What happened

The .NET team published in Microsoft DevBlogs blog An analysis of UI testing for UWP and WinUI 3 with MSTest. The thesis: a desktop application test must run through the application's actual UI dispatcher, and a single STA thread is not enough. A test that checks an application outside its real operating conditions gives management a false sense of security.

In our experience, this kind of confidence costs more than honestly having no tests: it is relied upon when making release decisions.

What Microsoft reported

  1. Starting with MSTest 4.5 and Microsoft.Testing.Platform (MTP) 2.5, the same UI-thread testing approach works for UWP and WinUI 3. The material lists the supported application models: classic and modern UWP, as well as packaged variants.

  2. The list is cut off in the excerpt available to us, so check the complete list against the original source. In the article's example, the test is marked with the `[UITestMethod]` attribute.

  3. It is asynchronous, calls `await Task.Yield()`, creates a `Grid`, and checks `grid.DispatcherQueue.HasThreadAccess`.

  4. Test setup, the asynchronous code inside it, and cleanup all run with access to the UI thread.

Why an STA thread is not enough

STA (single-threaded apartment) defines the threading model for COM: an object lives on one thread and must be accessed from that same thread.

The presence of such a thread does not mean it has a dispatcher that accepts UI tasks the way the application does. In WinUI 3, controls are tied to `DispatcherQueue`.

If a test creates a `Grid` on an arbitrary thread, it is testing a different system: production has a message queue and a defined execution order, while this test has neither.

The practical effect comes in two forms

In the first case, the test passes on a bare STA thread, while the same code fails in the application with a cross-thread access error.

In the second, tests fail because of environment-specific behavior, and the team gets used to ignoring them. In both cases, the result color stops conveying useful information.

What This Means for Business

  1. The biggest losses of time and money occur between “code written” and “working in production.”

  2. Automated tests help reduce that time and make it predictable.

  3. Time to use (TTU) measures how quickly a change reaches the user without breaking anything along the way.

  4. When UI tests run in conditions unlike production, releases must be checked manually and the tests become a formality. This is more noticeable in WinUI 3 and UWP desktop apps: the UI changes frequently, there is a lot of asynchronous code, and threading errors appear intermittently.

  5. Teams often spend weeks looking for such defects because they are difficult to reproduce.

  6. A test running on the correct thread makes them reproducible.

Map out your integration landscape

How it works technically

  1. A simple attribute hides nontrivial engineering.

  2. The runner must: - initialize the application environment and its dispatcher; - move test execution to the required thread; - preserve asynchronous semantics so that code continues on the same thread after `await`; - perform setup and cleanup in the same context.

  3. Microsoft Testing Platform handles this part, allowing developers to write a test that looks like a regular unit test.

  4. The simple interface here rests on complex work under the hood, paid for either with your engineers' time or with dependence on a ready-made library.

What C# / .NET teams should do

  1. We work with C# / .NET and regularly see the same mistakes in test environments. Here is a check that quickly shows what your test suite is built on:

  2. Take the three most painful defects from the past quarter related to threading or the UI.

  3. For each one, determine whether an existing automated test would have caught it. If not, identify the cause: the test environment or the absence of a test.

  4. If the environment is the cause, move those tests to the application's UI thread and compare failure rates before and after. This is a hypothesis that must be tested against your own code.

Source

It provides no figures on defect reduction, and we do not promise any. We integrate checks like these into the development process for integration projects. They are especially important in AI-native development: when an AI assistant writes and changes code, tests in real-world conditions remain the only independent judge. The author of the changes cannot decide alone whether the result is sufficient.

Conclusion

A test run outside the application's operating environment checks a fictional system.

Therefore, a coverage metric without asking “in what environment?” says very little about quality.

Ask your team what proportion of tests run in conditions that replicate production.

The answer shows what your engineers are spending their time on: delivering results or maintaining a green checkmark.

Source

“UWP and WinUI 3 apps: UI testing with MSTest,” the .NET team, Microsoft DevBlogs: https://devblogs.microsoft.com/dotnet/testing-uwp-and-winui-3-apps-with-mstest/. The author retains all rights to the material; it is used here as a starting point for analysis.

Discuss the article: UI test without a UI thread: the green checkmark,…

Enter your email or phone number so we can get back to you.

Send via: