使用 CodedUITest 测试 WPF 应用程序的正确方法是什么
拥有具有复杂 UI 的 WPF 应用程序，并希望为其编写 CodedUITest 脚本。 由于我对此不熟悉，因此我需要正确的指导/方法来编写 CodedUITest 脚本。 使用 Record & 不可能完成所有事情。玩东西是因为我们在 UI 上存在一些自定义控件，并且可以随时更改。
我想使用 C# 代码来完成这件事。从自定义网格获取特定记录并使用 C# 代码识别控件时遇到问题。
- 为了在 CodedUITest 中轻松识别，我应该控制哪些属性？
- 是否必须为所有控件提供 AutomationId？
- 对于 Treeview 和 grid 等动态控件需要做什么？
- 如何识别拖动和拖动？窗口的下降类型？
Having WPF application with complex UI and want to write CodedUITest scripts for the same.
Since I am new to this, I need proper guidance/approach to write CodedUITest script.
It wont be possible to do everything using Record & Play stuff because we have some custom control exist on UI and can be changed any time.
I want to do this thing using C# code. facing issues while getting particular record from custom grid and identify control using C# code.
- What kind of properties should I have on control for easy identification in CodedUITest?
- Is it compulsary to give AutomationId to all the controls?
- What needs to be done for dynamic controls like Treeview and grid?
- How can I identify drag & drop type of window?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
理论方面：
编码 UI 测试是为了进行 UI 回归测试。给定特定数据，您的 UI 应以特定方式做出反应。这个测试之王的想法是，一遍又一遍地给定相同的数据，UI 保持相同的行为方式。换句话说：如果给定某个数据集，您的 UI 改变了反应方式（基于记录），则测试应该中断。
事实：
编码的 UI 测试是一个测试框架，记录生成代码。您可以看到该代码，恕我直言，您应该看到这些东西是如何工作的。如果您需要更通用的编码 UI，可以通过修改生成的代码来实现。事实上，我强烈建议拆分生成的类和方法，并进行一些部落合作。
该代码生成一种 UI Map（具有引用测试所使用的 UI 对象的属性的类）。您可以手动定制该地图，添加或删除属性（毕竟，它只是代码）并创建您自己的更复杂的 UI 地图，事实上，通过努力，您甚至可以使地图“继承”其他地图（更多a la ASP.Net 母版页）。
在 WPF 中，您可以检查控件是否存在、其 UI 样式、其内容及其子控件（如果有）。
关于 AutomationID 主题，仅在您需要检查的控件中是强制性的。
关于D&D……我不知道。我从未为 D&D 做过 UI 测试。
The theoretical side:
Coded UI Tests are made to do UI regression tests. Given a certain data your UI should react in a specific way. The idea of this king of tests, is that given the same data over and over the UI keep behaving the same way. In other words: if given a certain dataset your UI changes how reacts (based on the recordings), the test should break.
The Practical fact:
Coded UI tests are a testing framework, and the recordings generates code. You can see that code, and IMHO you should see how that stuff works. If you need a more versatile coded UI you can achieve that by modifying the generated code. In fact I STRONGLY recommend to split the generated classes and methods, and do some clanup.
The code generates a sort of UI Map (a class with properties referencing the UI objects used by the test). You can tailor that map manually adding or removing properties (after all, it's just code) and create you own more complex UI map, in fact with effort, you can even make the maps "inherit" from other maps (more a la ASP.Net Master page).
In WPF you can check if a control exist or not, his UI style, it's content and his children (if there are).
On the AutomationID subject, is only mandatory in the controls you need to check.
On the D&D... I have no idea. I never did UI tests for D&D.