我正在开发一个包含“半大”应用程序GUI的项目。我想要执行编码UI测试的大约4-5个单独(复杂)页面,我得到的印象是创建多个UIMap是要走的路!来源:UIMap container,Using multiple UIMaps,More source,列表可以继续...
我的问题/想法:使用多个UIMaps是“不错的”,因为它:
但是为什么不仅仅是在多个部分类中削减UIMap?难道它还没有同样的优势吗?更进一步:在部分类中使用UIMap将阻止开发人员(我)增加代码的复杂性,如UIMap container。
答案 0 :(得分:4)
这个问题并非特定于CodedUI。使用部分类来模拟关注点的分离并不是正确的方法。
他们可能会使写一个类变得更容易,但是他们没有创建正确的关注分离(这是类存在背后的根本原因),因此不会使使用类更容易,因为从外部的角度来看,在一个或多个文件中编写代码的类之间没有任何区别。
举一个简单的例子,你将有自动完成功能,无差别地返回所有部分文件中所有类成员的平面列表。
当一个类是部分生成代码部分非生成代码,或者用不同语言编写时(例如,对于SL / WPF使用xaml和C#),使用部分。不同的位可能涵盖相同行为的部分,因此(从SoC的角度来看)将它们分组在同一个类下是有意义的,但从代码管理的角度来看,这两个部分需要分开。 这就是CodedUI使用partials(生成* .Designer.cs文件,而* .cs文件不生成)的原因。
如果您觉得需要创建部分内容以分离关注点,那么您应该退后一步并使用正确的SoC(即创建不同的类)。
在您公开的特定情况下,我会考虑为应用程序UI的不同部分创建UIMap(无论您是将UI的行为分为不同的窗口,还是窗口的各个部分等等 - 取决于它的复杂性)。
答案 1 :(得分:1)
使用多个UI地图而不是一个大地图有几个原因。其中一些是:
UI地图很难清理。随着测试套件的发展,UI Map获得越来越多的旧的和未使用的项目。几乎没有支持安全地删除不需要的碎片。
拥有多个UI地图意味着不同的测试开发人员可以同时提高工作效率,而不会在主UI地图中生成冲突项目。同时" .uimap" file是一个包含XML的简单文本文件。以与配置管理系统相同的方式成功合并这些文件将介于非常困难和不可能之间。
每个测试都有一个UI地图,意味着当不再需要测试时,可以丢弃其UI地图。所有对该测试的支持都被彻底抛弃。
拥有许多每个应用程序页面一个UI地图意味着抛弃一个UI地图并为页面创建一个新地图相对便宜。
Big UI Maps占用大量内存和CPU时间。有趣地使用大UI图可以使测试套件非常慢(我没有真正的证据)。大型UI地图具有大量成员和嵌套类。很容易想象,管理这样一个类所需的运行时数据很大,占用大量内存和CPU周期。
拥有多个UI地图而不是一个大地图意味着可以在不向主项目地图添加大量不必要项目的情况下进行实验。