在 WPF MVMM 应用程序中测试视图
我刚刚开始进入令人兴奋的 WPF 开发世界，已经担任 C++ 开发人员多年。
当然，测试具有丰富用户界面的应用程序一直很困难。传统上，使这一问题变得更加复杂的问题之一是，在大多数 Windows 应用程序中，UI、UI 逻辑和应用程序逻辑都是完全相互依赖的，无法单独进行测试。
我非常喜欢 MVVM 方法，它允许我将 UI 与应用程序分离，并在我的视图模型上运行大量自动化测试，我的所有逻辑都将在其下面，视图是一个相当愚蠢的客户端视图模型。
这一切都很好，并且巧妙地将应用程序逻辑的测试与应用程序 UI 分开。但是，它没有提供实际测试 UI 本身的解决方案。尽管视图通常包含很少的逻辑，但它仍然有可能包含大量各种类型的错误。
测试视图本身的当前技术水平是什么？
谢谢 汤姆
I'm just getting started in the exciting world of WPF development, having been a C++ developer for many years.
Testing applications with rich user interfaces has of course, always been hard. One of the problems compounding this has traditionally been that in most Windows apps, the UI, the UI logic and the App logic are all completely interdependent, and cannot be tested in isolation.
I'm very drawn to the MVVM approach that will allow me to separate the UI from the application, and run large amounts of automated tests on my view models, underneath which all my logic will be, with the view being a fairly dumb client of the view model.
That's all well and good, and neatly separates out testing of the application logic from the application UI. BUT, it provides no solution for actually testing the UI itself. Even though the view will typically contain very little logic, it will still have the potential to contain a huge amount of bugs of various kinds.
What's the current state of the art in testing the view itself?
Thanks
Tom
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这始终是一把双刃剑。我认为这是试图抓住唾手可得的果实并从那里开始建设。
理论上，MVVM 纯粹主义者会说视图背后的代码中绝对不存在任何逻辑。例如，使用 Prism 以及其他不同的框架可以帮助缓解这一问题。因此，从这个角度来看，它开始达到视图中不存在逻辑的地步……公平地说，我们接下来要开始测试绑定吗？但是，您可以根据应用程序的大小来确定该投资的回报率是多少？
我认为这可以归结为你的界限在哪里？例如，即使您正在测试视图，您也很可能会挂钩代码，此时您正在进行白盒测试。然后你可以从黑匣子角度争论，只有没有内部钩子的测试才是有效的。你可以看到它变成了一个循环的噩梦。
总的来说，我把注意力集中在大件物品上，然后从那里开始，测试在分配的时间内可能发生的事情。
这样想……有了 UI，您就可以开始测试每个按钮上的颜色以及位置等的惨败……这对我来说很愚蠢。在模型、视图模型、层上自动执行大量 UI 测试，如果您愿意，还可以测试视图的绑定。除此之外，我建议每个 UI 开发人员都应该在他们的工作站上进行临时手动工作。
This is always a double edged sword. I see it as attempting to grab the low hanging fruit and build from there.
In theory the MVVM purist would state that absolutely no logic exists in the View's code behind. Making use of Prism for instance can help alleviate this as well as other varying frameworks out there. So coming at it from this angle it begins to get to the point of no logic existing in the View...fair enough, are we then going to begin testing the bindings? You could, however depending on the sizing of the app what is the return on that investment?
What I think this boils down to is where do you draw the line? For instance, even if you are testing the View, you will most likely be hooking into the code, you're white box testing at that point. You then can argue the black box angle, that only testing without internal hooks is valid. You can see that it becomes a circular nightmare.
In general I have focused on the big ticket items and went from there, testing what was possible with the time allotted.
Think of it this way...with a UI you can begin this fiasco of testing the coloring on every button, along with the placement, etc... That's silly to me. Automate the bulk of UI testing at the Model, ViewModel, layer and if you so desire test the bindings of your View. Other then that I would suggest the ad-hoc manual effort every UI developer should be doing at their workstation.
WPF 和 MVVM 不会改变测试应用程序 UI 的过程。它只是从根本上减少了您在执行此操作时发现的缺陷数量，因为您通常在 UI 测试期间找到并修复的许多内容现在都可以在视图模型测试期间找到并修复。
WPF and MVVM doesn't change the process of testing an application's UI. It just radically reduces the number of defects you'll find while doing so, because so much of the stuff you'd normally find and fix during UI testing is now found and fixed during view model testing.