我继承了一个功能齐全但又凌乱的WPF MVVM应用程序。令我烦恼的是，几乎没有任何单元测试使得采用MVVM有点毫无意义。所以我决定添加一些。
在抓住低调的果实后，我开始陷入困境。有很多高度相互依赖的代码，特别是在视图中使用的属性和方法中。例如，一次通话引发了一系列的财产变化＆＃34;事件反过来引发其他呼叫等等。
这使得测试非常困难，因为你必须编写大量的模拟并设置大量属性来测试单个函数。当然，每个类只需要执行一次，然后在每次测试中重复使用mock和ViewModel。但它仍然是一种痛苦，这让我觉得这是错误的做事方式。当然，尝试打破代码并使其更加模块化会更好。
我不确定MVVM中的真实性。而且我处于恶性循环中，因为没有良好的测试，我担心通过重构编写好的测试来打破构建。事实上它的WPF MVVM是另一个问题，因为没有任何东西可以跟踪View和ViewModel之间的相互依赖性 - 粗心的名称更改可能会完全破坏某些东西。
我在C＃VS2013工作并抓住了ReSharper的试用版，看看它是否会有所帮助。使用起来很有趣，但到目前为止还没有。我的单元测试经验并不多。
那么 - 我怎样才能合理，有条不紊地安全地处理这个问题？我如何使用现有工具（并查看任何其他工具）来提供帮助？
答案 0 :(得分：5)
您的应用程序解决了一些现实问题，这就是业务逻辑所代表的问题。您的视图模型会围绕这些业务逻辑组件，即使它们（组件）尚未存在（作为单独的类）。
因此，您应该假设视图模型是轻量级，数据准备/重新排列对象。所有繁重的工作都应该在业务逻辑对象中完成。视图模型应该与原始数据一起提供，显示就绪。
记住这个重要的假设（VM = no BL）将业务逻辑组件移动到单独的，可能是模块化的项目中。以模块化方式组织BL通常会导致项目结构类似于：
Company.Project.Feature.Contract - 与功能相关的接口，实体，DTO Company.Project.Feature - 实施合同 Company.Project.Feature.Tests - 测试功能实施＃1和＃2的目标是达到放弃WPF并用console-interface替换它的状态应该只需要编写控制台接口并用BL层连接它。与WPF相关的所有内容（Views，ViewModels）都可以移位删除，这样的操作不应该破坏。
熟悉依赖注入和抽象的地方。介绍IoC容器。不要让您的代码依赖实施，使其依赖合同。每当视图模型依赖于BL实现时，将其与BL-abstraction交换。这将是使视图模型可测试的必要步骤之一。
这就是我的开始。这绝不是一个详尽的清单，我相信你会遇到坚持下去的情况不够。但那是什么 - working with legacy code is not an easy task.