测试时Application.Current.Dispatcher为空的解决方案探讨

我们的许多ViewModel中存在如下代码：

void Process()
{
    // 执行业务逻辑
    ...

    // 发送纯视觉相关的UI通知
    Application.Current.Dispatcher.BeginInvoke(() => ...);
}

使用Application.Dispatcher是为了确保代码运行在UI线程（Dispatcher.Current可能不是UI调度器），但这些被调度的代码不影响业务控制流或逻辑，测试ViewModel时Application.Current会为空，导致空引用异常。以下是对几种方案的分析及最优选择：

方案1：直接使用Application.Current?.Dispatcher #

这种写法不算代码坏味道，它通过空值传播运算符规避了空引用问题，测试场景下会直接跳过UI通知代码，完全符合“被调度代码对测试无影响”的前提。但缺点是ViewModel依然直接耦合WPF的Application静态类，后续如果更换UI框架，这块代码需要修改。

方案2：提供可模拟的IApplicationDispatcher #

这是最推荐的长期方案，符合依赖注入的设计思想。虽然看起来会给每个ViewModel增加构造参数，但通过依赖注入容器（如Autofac、Unity）可以实现自动注入，实际开发中并不会繁琐。

示例定义：

public interface IApplicationDispatcher
{
    void BeginInvoke(Action action);
}

public class WpfApplicationDispatcher : IApplicationDispatcher
{
    public void BeginInvoke(Action action)
    {
        Application.Current.Dispatcher.BeginInvoke(action);
    }
}

测试时可以注入空实现或模拟实现：

public class MockDispatcher : IApplicationDispatcher
{
    public void BeginInvoke(Action action)
    {
        // 测试时什么都不做，或按需执行
    }
}

这种方式彻底解耦了ViewModel与WPF的Dispatcher，不仅解决了测试问题，还提升了代码的可维护性和可扩展性。

方案3：测试初始化时创建Application实例 #

这种方式确实不够优雅，而且WPF的Application是单例设计，测试中共享静态实例容易导致测试间的状态污染，增加测试不稳定的风险，不推荐使用。

总结 #

• 若只是临时解决测试问题，且项目无框架迁移计划，方案1可以快速生效；
• 从长期代码质量和维护性考虑，方案2是最优选择，初期的少量基础设施搭建能带来长期收益。

内容的提问来源于stack exchange，提问作者wforl