我刚刚开始进入令人兴奋的 WPF 开发世界，多年来一直是 C++ 开发人员。
当然，测试具有丰富用户界面的应用程序一直很困难。传统上，与此相关的问题之一是，在大多数 Windows 应用程序中，UI、UI 逻辑和 App 逻辑都是完全相互依赖的，不能孤立地进行测试。
我非常喜欢 MVVM 方法，它允许我将 UI 与应用程序分开，并在我的视图模型上运行大量自动化测试，我的所有逻辑都将在它之下，而视图是一个相当愚蠢的客户端视图模型。
这一切都很好，并且巧妙地将应用程序逻辑的测试与应用程序 UI 分开。但是，它没有提供实际测试 UI 本身的解决方案。即使视图通常包含很少的逻辑，它仍然有可能包含大量的各种错误。
测试视图本身的最新技术是什么？
谢谢汤姆
这始终是一把双刃剑。我认为它试图抓住低垂的果实并从那里建造。
理论上，MVVM 纯粹主义者会声明 View 的代码中绝对不存在任何逻辑。例如，使用 Prism 可以帮助缓解这种情况以及其他不同的框架。因此，从这个角度来看，它开始达到视图中不存在逻辑的地步……很公平，我们是否要开始测试绑定？您可以，但是根据应用程序的大小，该投资的回报是多少？
我认为这归结为你在哪里画线？例如，即使您正在测试视图，您也很可能会挂接到代码中，此时您是白盒测试。然后，您可以争论黑盒角度，即只有没有内部钩子的测试才有效。你可以看到它变成了一个圆形的噩梦。
总的来说，我专注于大件物品，然后从那里开始，测试分配的时间可能发生的事情。
这样想……使用 UI，您可以开始测试每个按钮上的颜色以及位置等的惨败……这对我来说很愚蠢。在模型、视图模型、层自动执行大部分 UI 测试，如果您愿意，可以测试视图的绑定。除此之外，我建议每个 UI 开发人员都应该在他们的工作站上进行临时手动工作。
WPF 和 MVVM 不会改变测试应用程序 UI 的过程。它只是从根本上减少了您在这样做时会发现的缺陷数量，因为您通常在 UI 测试期间找到并修复的很多东西现在在视图模型测试期间找到并修复了。