重构WPF MVVM以提高可测试性

我继承了一个功能强大但混乱的WPF MVVM应用程序。令我烦恼的是，实际上没有单元测试，这使得采用MVVM有些毫无意义。所以我决定加一些

在抓到低垂的果实后，我开始遇到麻烦了。有很多高度相互依赖的代码，特别是在视图中使用的属性和方法中。例如，一个调用触发一系列“属性更改”事件是很常见的，而这些事件反过来又会触发其他调用，以此类推

这使得测试非常困难，因为您必须编写大量的模拟并设置大量属性来测试单个函数。当然，每个类只需执行一次，然后在每次测试中重新使用mock和ViewModel。但这仍然是一种痛苦，我觉得这是一种错误的方式。当然，最好尝试将代码分解，使其更加模块化

我不确定这在MVVM中有多现实。我陷入了一个恶性循环，因为如果没有好的测试，我担心通过重构来编写好的测试会破坏构建。事实上，它是WPF MVVM是一个更令人担忧的问题，因为没有任何东西能够跟踪视图和ViewModel之间的相互依赖关系——一个粗心的名称更改可能会完全破坏某些东西

我在C#VS2013工作，抓取了ReSharper的试用版，看看它是否有帮助。使用起来很有趣，但到目前为止还没有。我的单元测试经验并不丰富

那么，我怎样才能理智、有条理、安全地处理这个问题呢？我如何使用现有的工具（以及其他工具）来提供帮助

从核心开始--业务逻辑

您的应用程序解决了一些实际问题，这就是业务逻辑所代表的。视图模型围绕这些业务逻辑组件，即使它们（组件）还不存在（作为单独的类）

因此，您应该假设视图模型是轻量级的、数据准备/重排对象。所有繁重的工作都应该在业务逻辑对象中完成。视图模型应提供原始数据，显示就绪

模块化

牢记这一重要假设（VM=no BL），将业务逻辑组件移动到单独的、可能是模块化的项目中。以模块化方式组织BL通常会导致项目结构类似于：

• 公司、项目、功能、合同

  -与功能相关的接口、实体、DTO

• 公司.项目.功能

  -合同执行

• 公司.项目.功能.测试

  -功能实现测试

您使用#1和#2的目标是达到这样一种状态：放弃WPF并用控制台接口替换它只需要编写控制台接口并用BL层进行连接。与WPF相关的所有内容（视图、视图模型）都可以被删除，这样的操作不应该破坏任何东西

可测试性国际奥委会

在需要的地方熟悉依赖注入和抽象。介绍IoC容器。不要让你的代码依赖于实现，让它依赖于契约。只要视图模型依赖于BL实现，就用BL抽象交换它。这将是使视图模型可测试的必要步骤之一

这就是我的出发点。这绝对不是呼气清单，我相信你会遇到坚持不下去的情况。但事实就是这样--