重构WPF MVVM以提高可测试性

我已经继承了一个功能强大但很麻烦的WPF MVVM应用程序。令我烦恼的是，几乎没有任何单元测试使MVVM的采用毫无意义。所以我决定添加一些。重构WPF MVVM以提高可测试性

抓住了低垂的果实后，我开始遇到麻烦。有很多高度相互依赖的代码，特别是在视图中使用的属性和方法内部。例如，一次呼叫引发了一系列“财产变化”事件，这反过来引发了其他呼叫等等。

这使得测试非常困难，因为您必须编写大量模拟并设置大量属性来测试单个函数。当然，你只需要每节课做一次，然后在每次测试中重新使用你的模拟和ViewModel。但这仍然是一种痛苦，而且这让我感觉这是错误的做法。当然，尝试打破代码并使其更加模块化会更好。

我不知道在MVVM中有多现实。而且我处于一个恶性循环，因为没有好的测试，我担心通过重构来编写好的测试来打破构建。它是WPF MVVM的事实是一个进一步的关注，因为没有任何事情跟踪View和ViewModel之间的相互依赖性 - 一个不小心的名称更改可能会彻底破坏某些东西。

我正在C＃VS2013上工作，抓住了ReSharper的试用版，看看它是否有帮助。使用起来很有趣，但目前还没有。我的单元测试经验并不广泛。

那么 - 我该如何合理，有条理和安全地处理这个问题？我怎样才能使用我现有的工具（并查看其他工具）来提供帮助？

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

因此，您应该认为该视图模型是轻量级,数据准备/重新排列对象。所有繁重的工作应该在业务逻辑对象内完成。视图模型应该与原始数据一起提供，显示就绪。

模块化

铭记这个重要的假设（VM =无BL）移动业务逻辑组件分离，可能模块化项目。以模块化的方式组织BL往往会导致项目结构类似：

您的目标是＃1和＃2将达到放弃WPF并用控制台接口替换它的状态，只需要编写控制台界面并将其与BL层连接即可。一切WPF相关（视图，ViewModels）可能会被移位删除，这种行为不应该打破一件事。

IoC的可测性

在需要熟悉依赖注入和抽象。介绍IoC容器。不要让你的代码依赖执行，使其依赖合同。每当视图模型依赖于BL实现时，将其与BL抽象交换。这将是使视图模型可测试的必要步骤之一。

这就是我将如何开始。绝不是这份详尽的清单，我相信你会遇到坚持它的情况是不够的。但这就是它 - working with legacy code is not an easy task.

2014-10-31 13:03:02

回答