C# 编码UI测试：创建多个单独的UIMap类而不是多个部分UIMap类背后的原因是什么？

我正在从事一个项目，其中包括一个“半大型”应用程序GUI。我想在大约4-5个单独（复杂）的页面上执行编码的UI测试，我得到的印象是，创建多个UIMaps是一种方法！资料来源：，名单还可以继续

我的问题/想法：使用多个UIMaps“很好”，因为它：

允许更分类的代码结构

允许开发人员之间更轻松的合作

使代码不那么难以维护

---

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

这个问题实际上并不特定于CodedUI。使用分部类来模拟关注点分离不是正确的方法

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

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

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

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

---

在您所公开的特定情况下，我将考虑为应用程序UI的不同部分创建UIMAP（无论您是根据UI的复杂性将其UI划分为不同窗口或窗口等）。

< P>使用多个UI映射而不是一个大地图有几个原因。其中包括：

• UI映射很难清理。随着测试套件的发展，UI映射将获得越来越多的旧项和未使用项。实际上没有安全移除不需要的碎片的支持

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

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

• 在应用程序的每个页面上都有一个UI映射，这意味着扔掉一个UI映射，为页面创建一个新的UI映射相对便宜

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

• 拥有多个UI映射而不是一个大的UI映射意味着可以在不向主项目映射添加大量不必要项的情况下进行实验

---

前两个链接已断开/需要登录才能发出通知！现在已经修好了。非常感谢您的回答！我非常清楚拆分UIMap的优点，但我想假设，使用部分UIMap类仍然可以满足这些优点。。。当然，您的第五点（内存和CPU使用）在使用部分UIMap类时会出现问题，但我也没有发现任何证据——我最好的猜测是，Visual Studio编译器magic足够聪明，不会实例化测试方法期间未使用的类的字段和方法。毕竟，UIMap是在每个testmethod之间分配的。你认为这是合理的吗？@Yakitawa如何将UI映射拆分为多个文件，每个文件都启动

部分类UIMap{

在不失去UI地图编辑器所有功能的情况下？谢谢你的回答！我不会使用分部类…但是！我在wiki端找到了一个例子，它将SoC表示为分部类。Dijkstra将SoC描述为一种帮助程序员分离关注点的方法，而不一定帮助程序分离关注点。Woul在我的例子中，使用分部类并且仍然有一个“好的”SoC不是很明智吗？我认为分部类非常适合自动生成的代码，但这是否应该排除它对分割UIMaps的好处呢？我认为SoC在今天的C中变得更有用，因为该语言严格地强制作用域（例如，与Powershell或Javascript相反），通过避免全局状态的现代开发技术（通过使用注入和避免静态对象），以及我们使用的工具以比过去更高的级别呈现我们的代码这一事实（想想与Intelisense或ReSharper的对比，因为这些工具的部分是没有意义的）.