UI-тест без UI-потока: зелёная галочка, которой нельзя верить

Начиная с MSTest 4.5 и Microsoft.Testing.Platform (MTP) 2.5 один и тот же подход к тестированию в UI-потоке работает для UWP и WinUI 3. В материале перечислены поддерживаемые модели приложений: классическое и современное UWP, а также упакованные варианты.

Перечень в доступном нам фрагменте обрывается, поэтому полный список сверяйте по первоисточнику. В примере из статьи тест помечен атрибутом `[UITestMethod]`.

Он асинхронный, делает `await Task.Yield()`, создаёт `Grid` и проверяет `grid.DispatcherQueue.HasThreadAccess`.

Установка теста, асинхронный код внутри него и очистка выполняются с доступом к UI-потоку.

Основные потери времени и денег приходятся на промежуток между «написал код» и «работает в проде».

Автотесты нужны, чтобы сократить его и сделать предсказуемым.

Время до результата (TTU, time to use) измеряется тем, как быстро изменение дошло до пользователя и ничего не сломало по дороге.

Если UI-тесты запускаются в условиях, непохожих на боевые, релиз приходится проверять руками, а сами тесты остаются формальностью. У настольных приложений на WinUI 3 и UWP это заметнее: интерфейс меняется часто, асинхронного кода много, а ошибки потоков проявляются нерегулярно.

Такие дефекты команды нередко ищут неделями, потому что их трудно воспроизвести.

Тест в правильном потоке делает их воспроизводимыми.

За простым атрибутом стоит нетривиальная инженерия.

Раннер должен: - поднять окружение приложения и его диспетчер; - перенести выполнение теста в нужный поток; - сохранить асинхронную семантику, чтобы после `await` код продолжал работать в том же потоке; - выполнить инициализацию и очистку в том же контексте.

Эту часть берёт на себя Microsoft Testing Platform, и разработчик пишет тест, который выглядит как обычный модульный.

Простой интерфейс здесь стоит на сложной работе под капотом, и платить за неё приходится либо временем своих инженеров, либо зависимостью от готовой библиотеки.

Мы работаем с C# / .NET и регулярно видим одни и те же ошибки в тестовых контурах. Вот проверка, которая быстро показывает, на чём стоит ваш набор тестов:

Возьмите три самых болезненных дефекта за последний квартал, связанных с потоками или интерфейсом.

Для каждого выясните, поймал бы его существующий автотест. Если нет, определите причину: окружение теста или отсутствие самого теста.

Если причина в окружении, перенесите такие тесты в UI-поток приложения и сравните долю падений до и после. Это гипотеза, и проверять её нужно на своём коде.