编码的 UI 测试：创建多个单独的 UIMap 类而不只是多个部分 UIMap 类的原因是啥？

Posted 2023-03-27

【中文标题】编码的 UI 测试：创建多个单独的 UIMap 类而不只是多个部分 UIMap 类的原因是啥？

【英文标题】：Coded UI testing: What is the reasoning behind creating multiple individual UIMap classes instead of just multiple partial UIMap classes?编码的 UI 测试：创建多个单独的 UIMap 类而不只是多个部分 UIMap 类的原因是什么？

【发布时间】：2015-11-04 22:58:46

【问题描述】：

我正在开发一个包含“半大型”应用程序 GUI 的项目。我想在大约 4-5 个单独的（复杂的）页面上执行编码 UI 测试，我的印象是创建多个 UIMaps 是要走的路！资料来源：UIMap container、Using multiple UIMaps、More source，名单还可以继续……

我的问题/想法：使用多个 UIMap 是“不错的”，因为它：

允许更分类的代码结构 让开发者之间的合作更轻松 使代码的维护变得不那么令人生畏。

但是为什么没有人只是将 UIMap 分成多个部分类？不还是一样的优点吗？更进一步：在部分类中使用 UIMap 将防止开发人员（我）增加代码的复杂性，例如 UIMap container。

【问题讨论】：

前两个链接已损坏/需要登录

感谢您的通知！现在已经修复了。

【参考方案1】：

这个问题并不是 CodedUI 所特有的。使用部分类来模拟关注点分离并不是正确的方法。

它们可能使编写一个类更容易，但它们并没有创建适当的关注点分离（这是类存在背后的根本原因），因此不会使用 em> 类更容易，因为从外部的角度来看，在一个或多个文件中编写代码的类之间根本没有区别。

举个简单的例子，您将让自动完成功能返回一个包含所有部分文件的类的所有成员的平面列表，没有区别。

当一个类是部分生成的代码部分非生成的代码，或用不同的语言编写（例如，用于 SL/WPF 的 xaml 和 C#）时，使用部分。不同的位可能涵盖相同行为的部分，因此（从 SoC 的角度来看）将它们分组到同一类下是有意义的，但从代码管理的角度来看，这两个部分需要分开。 这就是 CodedUI 使用 partials 的原因（*.Designer.cs 文件生成，而 *.cs 文件不生成）。

如果您觉得需要创建部分以实现关注点分离，那么您可能应该退后一步并使用适当的 SoC（即创建不同的类）。

在您公开的特定情况下，我会考虑为您的应用程序 UI 的不同部分创建 UIMaps（您是否将 UI 的行为分成不同的窗口或窗口的部分等 - 取决于它的复杂性)。

【讨论】：

感谢您的回答！我不会使用部分类......但是！我在 wiki 端找到了一个示例，en.wikipedia.org/wiki/Separation_of_concerns，它将 SoC 表示为部分类。 Dijkstra 将 SoC 描述为一种帮助程序员分离关注点的方式，而不一定帮助程序分离关注点。在我的情况下，使用部分类并且仍然拥有“好”的 SoC 是否仍然是明智的？我看到部分类非常适合自动生成的代码，但这是否应该排除它对拆分 UIMap 的好处？

我认为 SoC 在今天的 C# 中变得更加有用，因为该语言严格执行范围界定（例如，与 Powershell 或 javascript 相反），通过我们避免全局状态的现代开发技术（通过使用注入和避免静态对象），并且我们使用的工具以比过去常见的更高级别呈现我们的代码（想想 VS Intelisense 或 ReSharper，因为这些工具的部分是没有意义的）。

【参考方案2】：

使用多个 UI 地图而不是一张大地图有几个原因。其中一些是：

UI 地图很难清理。随着测试套件的发展，UI Map 会获得越来越多的旧项目和未使用项目。几乎不支持安全移除不需要的部分。

拥有多个 UI 地图意味着不同的测试开发人员可以同时提高工作效率，而不会在主 UI 地图中生成冲突项目。虽然“.uimap”文件是一个简单的文本文件，但它包含 XML。以配置管理系统常见的方式成功合并这些文件将非常困难和不可能。

拥有多个 UI 映射，每个测试一个，这意味着当不再需要测试时，可以丢弃它的 UI 映射。对特定测试的所有支持都被彻底丢弃。

拥有许多 UI 地图，应用程序的每个页面都有一个，这意味着丢弃 UI 地图并为页面创建新的地图相对便宜。

大 UI 地图会消耗大量内存和 CPU 时间。有趣的是，使用大 UI 地图会使测试套件变得非常缓慢（我没有这方面的真实证据）。一个大的 UI 地图有大量的成员和嵌套的类。不难想象，管理这样一个类所需的运行时数据很大，并且会消耗大量内存和 CPU 周期。

拥有许多 UI 地图而不是一个大地图意味着可以在不向主项目地图添加大量不必要的项目的情况下进行试验。

【讨论】：

非常感谢您的回答！我非常了解拆分 UIMap 的优势，但我想假设，使用部分 UIMap 类仍然可以满足这些优势......当然，使用部分 UIMap 的第 5 点（内存和 CPU 使用率）将是一个问题UIMap 类，但我也没有找到任何证据——我最好的猜测是，Visual Studios 编译器的魔法足够聪明，不会实例化在测试方法期间未使用的类的字段和方法。毕竟，UIMap 是设置在每个测试方法之间的。你觉得这靠谱吗？

@Yakitawa 您如何将 UI 地图拆分为多个文件，每个文件都以 partial class UIMap 开头，而不会失去 UI 地图编辑器的所有功能？