1. 为什么WPF项目必须重视测试？

很多刚开始做WPF开发的朋友，可能和我当年一样，觉得把界面做漂亮、功能跑通就万事大吉了。直到项目越来越大，改一个地方，十个地方报错；加一个新功能，老功能莫名其妙挂了。这时候才捶胸顿足，后悔没早点把测试搞起来。我踩过不少坑，今天就想和你聊聊，怎么在WPF项目里，把单元测试和UI测试这两件事，做得既高效又实用。

单元测试和UI测试，听起来像是两座大山，但其实它们是帮你“躺平”的利器。单元测试管的是你后台的“脑子”——那些ViewModel里的业务逻辑、数据转换、命令执行对不对。它跑得快，不依赖界面，就像给你的代码逻辑上了一道保险。而UI测试管的是前台的“脸面”和“手脚”——按钮点了有没有反应、数据绑定对不对、窗口跳转顺不顺畅。它模拟真实用户操作，确保用户看到的和体验到的东西是靠谱的。

把这两者结合起来，你的WPF应用才能算得上“健壮”。不然，一个看似华丽的界面，背后可能是一堆脆弱的代码，上线后分分钟让你体验“救火队员”的刺激。接下来，我就结合自己这些年摸爬滚打的经验，从工具选择到实战技巧，一步步带你上手。

2. 单元测试实战：从零搭建可靠的后台逻辑防护网

单元测试的核心思想是“隔离测试”。我们不想在测一个计算逻辑时，还得去连数据库、等网络请求。所以，第一步就是选好趁手的兵器。

2.1 测试框架与模拟库的选择

在.NET生态里，NUnit、xUnit 和 MSTest 是三大主流单元测试框架。我个人的偏好是 xUnit，因为它更轻量、哲学更纯粹（比如 [Fact] 代替 [TestMethod]，强制每个测试类一个实例，减少了测试间的意外耦合）。但用 MSTest 也没问题，特别是如果你的团队或项目已经习惯了Visual Studio的深度集成。

光有框架还不够。WPF项目大量使用 INotifyPropertyChanged、ICommand 以及各种服务接口（如 IDialogService、IDataRepository）。要让测试跑得快且稳定，我们必须把这些依赖“模拟”出来。这里我强烈推荐 Moq 库，它用起来非常直观。再搭配一个专门为测试WPF/MVVM而生的神器——Fody.PropertyChanged（或者用它的 [ImplementPropertyChanged] 属性），它能帮我们自动生成属性变更通知的代码，让测试更专注于行为逻辑。

下面是一个典型的项目结构，你可以参考：

MyWpfApp/
├── MyWpfApp.sln
├── src/
│   └── MyWpfApp/
│       ├── Views/
│       ├── ViewModels/
│       ├── Models/
│       └── Services/
└── tests/
    ├── MyWpfApp.UnitTests/
    │   ├── ViewModels/
    │   ├── Services/
    │   └── MyWpfApp.UnitTests.csproj
    └── MyWpfApp.UITests/

单元测试项目需要引用主项目，以及 xunit、Moq、xunit.runner.visualstudio 这些NuGet包。

2.2 测试ViewModel：命令、属性和异步操作

ViewModel是WPF MVVM模式的核心，也是单元测试的重中之重。我们来看几个典型的测试场景。

场景一：测试一个同步命令。 假设我们有个登录按钮，点击后需要验证用户名和密码。

// 在主项目的 ViewModels/LoginViewModel.cs 中
public class LoginViewModel : INotifyPropertyChanged
{
    private string _username;
    public string Username
    {
        get => _username;
        set { _username = value; OnPropertyChanged(); }
    }
    // ... Password 属性类似

    public ICommand LoginCommand { get; }

    public LoginViewModel(IAuthenticationService authService)
    {
        _authService = authService;
        LoginCommand = new RelayCommand(ExecuteLogin, CanExecuteLogin);
    }

    private bool CanExecuteLogin(object parameter) => !string.IsNullOrWhiteSpace(Username) && !string.IsNullOrWhiteSpace(Password);

    private void ExecuteLogin(object parameter)
    {
        // 调用认证服务
        var isSuccess = _authService.Authenticate(Username, Password);
        // ... 处理登录结果
    }
}

对应的单元测试会这样写：

// 在测试项目的 ViewModels/LoginViewModelTests.cs 中
public class LoginViewModelTests
{
    [Fact]
    public void LoginCommand_CanExecute_ReturnsFalse_WhenCredentialsAreEmpty()
    {
        // Arrange: 创建模拟的依赖服务，并初始化ViewModel
        var mockAuthService = new Mock<IAuthenticationService>();
        var vm = new LoginViewModel(mockAuthService.Object);

        // Act & Assert: 测试命令的可执行状态
        vm.Username = "";
        vm.Password = "somepassword";
        Assert.False(((RelayCommand)vm.LoginCommand).CanExecute(null));

        vm.Username = "user";
        vm.Password = "";
        Assert.False(((RelayCommand)vm.LoginCommand).CanExecute(null));
    }

    [Fact]
    public void ExecuteLogin_CallsAuthenticationService_WithCorrectParameters()
    {
        // Arrange
        var mockAuthService = new Mock<IAuthenticationService>();
        mockAuthService.Setup(s => s.Authenticate(It.IsAny<string>(), It.IsAny<string>())).Returns(true);
        var vm = new LoginViewModel(mockAuthService.Object) { Username = "testUser", Password = "testPass" };

        // Act
        ((RelayCommand)vm.LoginCommand).Execute(null);

        // Assert: 验证服务方法是否被以预期的参数调用了一次
        mockAuthService.Verify(s => s.Authenticate("testUser", "testPass"), Times.Once);
    }
}

这里的关键是使用 Moq 的 Verify 方法来断言依赖服务的方法被正确调用了，而不是真的去执行认证逻辑。这就是“隔离”的精髓。

场景二：测试异步命令和属性通知。 现代应用离不开异步操作，比如从网络加载数据。我们常用 AsyncRelayCommand（来自 CommunityToolkit.Mvvm 库）或自己封装。

public class DataViewModel : INotifyPropertyChanged
{
    private bool _isLoading;
    public bool IsLoading
    {
        get => _isLoading;
        private set { _isLoading = value; OnPropertyChanged(); }
    }

    public IAsyncRelayCommand LoadDataCommand { get; }

    public DataViewModel(IDataService dataService)
    {
        LoadDataCommand = new AsyncRelayCommand(LoadDataAsync);
    }

    private async Task LoadDataAsync()
    {
        IsLoading = true;
        try
        {
            // 模拟耗时操作
            await Task.Delay(1000);
            // ... 实际加载数据
        }
        finally
        {
            IsLoading = false;
        }
    }
}

测试这个ViewModel，我们需要检查两件事：一是命令执行期间 IsLoading 属性是否正确地从 false 变为 true 再变回 false；二是异步操作本身是否被触发。这里我们可以利用 PropertyChanged 事件来追踪属性变化。

[Fact]
public async Task LoadDataCommand_Executes_SetsAndUnsetsIsLoading()
{
    var mockDataService = new Mock<IDataService>();
    var vm = new DataViewModel(mockDataService.Object);
    var propertyChangedLog = new List<string>();
    vm.PropertyChanged += (sender, args) => propertyChangedLog.Add(args.PropertyName);

    // Act
    await vm.LoadDataCommand.ExecuteAsync(null);

    // Assert
    // 检查 IsLoading 属性变化序列
    Assert.Contains(nameof(DataViewModel.IsLoading), propertyChangedLog);
    // 更精确的检查可以记录属性值的变化顺序
    Assert.False(vm.IsLoading); // 最终状态应为 false
}

注意：测试异步代码时，务必使用 async/await，避免使用 .Result 或 .Wait()，否则容易造成死锁，特别是在涉及UI线程同步上下文的测试中。

2.3 处理依赖与静态方法

有时候你会遇到一些“硬骨头”，比如代码里直接调用了 MessageBox.Show 或者 File.ReadAllText。这些静态方法或具体类会严重阻碍单元测试。我们的策略是 “依赖注入” 和 “接口隔离”。

方法一：包装静态类。 对于 File 操作，我们可以创建一个 IFileSystem 接口。

public interface IFileSystem
{
    string ReadAllText(string path);
    void WriteAllText(string path, string contents);
}
public class RealFileSystem : IFileSystem { /* 包装 System.IO.File 的方法 */ }
public class MockFileSystem : IFileSystem { /* 用于测试的内存模拟 */ }

然后在ViewModel中通过构造函数注入 IFileSystem，测试时传入 MockFileSystem 即可。

方法二：使用适配器模式处理对话框。 对于 MessageBox，我们可以创建一个 IDialogService。

public interface IDialogService
{
    MessageBoxResult ShowMessage(string message, string caption, MessageBoxButton buttons);
}

在真实应用中，它的实现会调用真正的 MessageBox；在测试中，我们可以模拟一个返回预定结果的实现，这样测试用例就可以稳定地验证ViewModel在用户点击“确定”或“取消”后的行为了。

3. UI测试实战：让自动化成为你的“第二双眼睛”

单元测试保证了后台逻辑坚固，但用户最终接触的是界面。一个按钮绑定错了命令，或者一个数据模板在特定数据下显示异常，单元测试很难发现。这时候就需要UI测试出场了。UI测试虽然运行慢一些，但它是验收功能完整性的关键。

3.1 主流UI测试框架横评

几年前，微软的 Coded UI Test 是主流，但它现在已被弃用。目前WPF UI测试主要有两个方向：

  1. 基于控件的测试（推荐用于WPF）： 代表是 Appium（配合 WinAppDriver）和 TestStack.White。它们通过UI自动化树来识别和操作控件（按钮、文本框等）。WinAppDriver 是微软官方维护的，它实现了WebDriver协议，意味着你可以用写Selenium测试的语法（C#、Java、Python等）来测试Windows桌面应用，生态和社区支持很好。
  2. 基于图像的测试： 比如 SikuliX 或 Appium + OpenCV。它通过截图和图像识别来定位元素，不关心底层控件结构。优点是对于自定义绘制或游戏界面有效，缺点是运行慢、受分辨率/缩放影响大、维护成本高。

对于大多数标准WPF控件构建的应用，我强烈推荐 Appium + WinAppDriver 的组合。它稳定、标准，而且测试脚本的写法和你做Web自动化测试非常相似，学习曲线平缓。

3.2 使用Appium + WinAppDriver搭建测试环境

第一步是安装配置。你需要：

  1. 安装 WinAppDriver。从GitHub releases页面下载MSI安装包，安装后最好将其设置为开机自启（可以在服务中设置）。
  2. 在测试项目中，通过NuGet安装 Appium.WebDriver 包。

一个最简单的启动WPF应用并点击按钮的测试看起来是这样的：

using OpenQA.Selenium;
using OpenQA.Selenium.Appium;
using OpenQA.Selenium.Appium.Windows;
using OpenQA.Selenium.Remote;

public class MainWindowUITests : IDisposable
{
    private WindowsDriver<WindowsElement> _driver;

    public MainWindowUITests()
    {
        // Appium WinAppDriver 的服务器地址
        var options = new AppiumOptions();
        options.AddAdditionalCapability("app", @"C:\Path\To\Your\WpfApp.exe");
        options.AddAdditionalCapability("platformName", "Windows");
        options.AddAdditionalCapability("deviceName", "WindowsPC");

        // 连接到本地WinAppDriver服务器
        _driver = new WindowsDriver<WindowsElement>(new Uri("http://127.0.0.1:4723"), options);
    }

    [Fact]
    public void ClickButton_ShouldUpdateTextBlock()
    {
        // 使用各种定位器查找元素。Name通常对应控件的 x:Name 或 AutomationProperties.Name
        var button = _driver.FindElementByName("MyButton");
        var textBlock = _driver.FindElementByName("ResultTextBlock");

        // 执行操作
        button.Click();

        // 断言结果
        Assert.Equal("Hello, UI Test!", textBlock.Text);
    }

    public void Dispose()
    {
        _driver?.Quit();
    }
}

提示：为了让WinAppDriver能可靠地识别你的WPF控件，务必为重要的交互控件设置 x:Name 或使用 AutomationProperties.AutomationId 属性。AutomationId 是UI自动化中的最佳标识符，因为它最稳定，不像 Name 可能随语言变化。

3.3 编写稳定、可维护的UI测试用例

UI测试最怕“脆弱”——今天能跑过，明天就因为界面微调而失败。要写出健壮的测试，有几个原则：

原则一：使用可靠的定位策略。 优先级是：AutomationId > Name > ClassName > XPath。尽量避免使用基于绝对位置或索引的查找。在XAML中设置 AutomationProperties.AutomationId：

<Button x:Name="SubmitBtn" Content="提交" AutomationProperties.AutomationId="Login_Submit_Button"/>

原则二：引入显式等待，告别“Thread.Sleep”。 不要用 Thread.Sleep(5000) 这种硬等待，效率低且不可靠。应该使用WebDriver的“显式等待”机制，等待某个条件成立。

using OpenQA.Selenium.Support.UI;
using OpenQA.Selenium.Appium.Windows;

var wait = new WebDriverWait(_driver, TimeSpan.FromSeconds(10));
// 等待直到某个元素出现并可点击
var button = wait.Until(d => d.FindElement(By.Name("MyButton")));
// 等待直到文本包含特定内容
wait.Until(d => d.FindElement(By.Name("StatusText")).Text.Contains("完成"));

原则三：页面对象模式（Page Object Model, POM）。 这是提升UI测试可维护性的核心设计模式。将每个窗口或页面封装成一个类，类内部包含元素定位器和常用的操作/验证方法。测试脚本只调用这些高层方法，不直接操作底层元素。

public class LoginPage
{
    private readonly WindowsDriver<WindowsElement> _driver;

    public LoginPage(WindowsDriver<WindowsElement> driver) => _driver = driver;

    // 元素定位器
    private WindowsElement UsernameInput => _driver.FindElementByAccessibilityId("UsernameBox");
    private WindowsElement PasswordInput => _driver.FindElementByAccessibilityId("PasswordBox");
    private WindowsElement LoginButton => _driver.FindElementByAccessibilityId("Login_Submit_Button");
    private WindowsElement ErrorMessage => _driver.FindElementByAccessibilityId("Login_Error_Text");

    // 页面操作
    public void Login(string username, string password)
    {
        UsernameInput.SendKeys(username);
        PasswordInput.SendKeys(password);
        LoginButton.Click();
    }

    public string GetErrorMessage() => ErrorMessage.Text;
}

// 在测试类中使用
[Fact]
public void Login_WithInvalidCredential_ShowsErrorMessage()
{
    var loginPage = new LoginPage(_driver);
    loginPage.Login("wrong", "wrong");
    Assert.Contains("无效", loginPage.GetErrorMessage());
}

这样，如果登录页面的按钮ID变了，你只需要修改 LoginPage 类中的一个地方，所有测试用例就都修复了。

原则四：处理好常见的异步和动态内容。 WPF应用经常有数据绑定、动画、延迟加载。在测试中，你的等待条件要针对这些场景设计。例如，等待一个列表的数据项加载完成：

// 假设列表项是一个自定义控件，内部有一个TextBlock显示名称
wait.Until(d =>
{
    var items = d.FindElementsByClassName("MyListItemClass");
    return items.Count > 0 && !string.IsNullOrEmpty(items[0].Text);
});

4. 集成与进阶：打造高效的测试工作流

单元测试和UI测试各司其职，但把它们融入开发流程，才能产生最大价值。我习惯在团队中推行“测试左移”，也就是在写功能代码的同时甚至之前，就考虑测试。

4.1 测试的组织与运行策略

我建议将测试分层，并在持续集成（CI）管道中配置不同的运行策略：

  • 提交前（本地/预提交钩子）： 强制运行所有单元测试。它们很快，几秒钟就能给你反馈。
  • 持续集成服务器（如Jenkins, Azure DevOps, GitHub Actions）： 每次代码推送，都运行完整的单元测试套件和核心的、稳定的UI测试（例如冒烟测试）。可以将UI测试部署到一个专用的、环境干净的测试虚拟机上去跑。
  • 夜间构建： 运行全部的UI测试套件。因为UI测试慢，放在夜间跑，第二天早上看报告。

在Azure Pipelines或GitHub Actions的YAML配置里，你可能会看到这样的步骤：

- task: VSTest@2
  inputs:
    testSelector: 'testAssemblies'
    testAssemblyVer2: '**\*UnitTests*.dll'
    searchFolder: '$(Build.SourcesDirectory)/tests'
    testFiltercriteria: 'TestCategory!=Integration&TestCategory!=UI'
- script: |
    # 启动 WinAppDriver 服务
    Start-Process -FilePath "C:\Program Files (x86)\Windows Application Driver\WinAppDriver.exe"
    # 运行UI测试
    dotnet test .\tests\MyWpfApp.UITests\ --filter "TestCategory=UI"

记得在UI测试类上打上 [Trait("Category", "UI")] 这样的标签，方便用 --filter 进行筛选。

4.2 测试数据管理与Mock策略

测试数据的管理是个学问。对于单元测试，我倾向于使用 内联数据（xUnit的 [InlineData]）和 成员数据（[MemberData]）来覆盖不同的输入场景。

[Theory]
[InlineData(1, 2, 3)]
[InlineData(-1, 1, 0)]
[InlineData(0, 0, 0)]
public void Add_ReturnsCorrectSum(int a, int b, int expected)
{
    var calc = new Calculator();
    var result = calc.Add(a, b);
    Assert.Equal(expected, result);
}

对于复杂对象，可以建立一个“测试数据工厂”（Test Data Builder）来构造。对于UI测试，特别是需要登录状态的测试，可以考虑让应用在测试模式下启动时，自动注入一个测试账户，或者通过API接口预先准备好测试数据。绝对要避免在UI测试脚本里硬编码数据库连接去修改数据，这会让测试变得极其脆弱且难以移植。

Mock策略上，除了之前提到的对服务接口的Mock，对于时间（DateTime.Now）、随机数（Random）这类“非确定性”依赖，也应该进行抽象和Mock，以确保测试的重复性。

4.3 常见陷阱与调试技巧

最后，分享几个我踩过的坑和解决办法：

  • “幽灵点击”问题： UI测试中，Click() 方法执行了，但好像没效果。这可能是因为控件还没真正准备好接收点击（例如，动画还没结束）。解决方法是在点击前，增加一个等待条件，检查控件是否 Enabled 并且 Displayed。
  • 控件找不到： 这是最常见的问题。首先，用 Inspect.exe（Windows SDK自带）或 FlaUInspect 工具查看运行中应用的UI自动化树，确认你使用的定位器（如 AutomationId）是否真的存在且唯一。其次，检查是否有多个窗口，焦点是否在正确的窗口上。
  • 测试在CI上失败，本地却成功： 这通常是环境差异造成的。检查CI机器的屏幕分辨率、缩放比例是否与本地一致。WinAppDriver对缩放设置比较敏感。可以考虑在CI机器上锁定显示设置，或者以特定的缩放比例运行测试。
  • 异步操作导致断言过早： 这是UI测试的经典问题。牢记：任何可能引起界面更新的操作（点击、输入、数据加载）之后，都要用显式等待去等待你的预期状态出现，然后再进行断言。

调试UI测试时，一个很实用的办法是插入短暂的暂停，并配合截图功能。Appium WebDriver有 GetScreenshot 方法，可以在测试失败时自动截图保存，帮你快速定位失败时的界面状态。

说到底，写测试是一种投资。前期多花一小时编写严谨的测试，后期可能就能省下十小时熬夜排查线上bug的时间。尤其是对于WPF这种长期维护的企业级客户端应用，一套覆盖全面的自动化测试就是你的安全网和信心来源。刚开始可能会觉得有点慢，有点麻烦，但当你看到每次重构后，测试套件绿灯通过时的那种安心感，你就会觉得这一切都值了。

# 单元测试
Logo
乐奇 Rokid 开放社区

更多推荐

cover

国庆文旅安保上新！AR智能眼镜守护景区，黑科技护航假期出游

avatar 乐奇 Rokid 开放社区
cover

2027中国深圳智能穿戴产业链展览会

avatar 乐奇 Rokid 开放社区
cover

化工行业AR巡检找哪家公司比较好

avatar 乐奇 Rokid 开放社区