对于可测试性,为ComboBox添加功能的正确方法是什么?

时间:2009-01-28 10:10:02

标签: c# .net winforms unit-testing testability

“增强”组合框的所需功能是一种快速查找方法。组合框中的每个项目都有一个ToString()方法,以便它们可以显示在下拉列表中。单击下拉列表中的项目时,组合框的观察者会收到选择的通知。

此外,每次组合框中的键入文本发生变化时,都会生成一个“候选人”列表,由下拉列表中包含到目前为止输入的文本的所有项目组成。点击输入会将您带到该列表中的第一个候选者,重复点击输入循环列表。

我通过从ComboBox派生实现了这个功能 - 我觉得这很有意义,因为我仍然在功能上留下了一个组合框,它只是增加了这个“QuickFind”功能。然而,创建候选列表并在其中循环的逻辑虽然简单,但并非完全无关紧要,并且会享受一些测试。

然而,正如here所示,仅仅通过构建它并刺激我添加的额外例程来测试ComboBox似乎并不那么容易 - 它需要存在于表单上才能实现行为与在应用程序中的行为方式相同。对于测试简单组合框的简单添加,这似乎太费力了!

循环通过候选者的代码中没有任何内容特定于我的应用程序但是 - 我创建了一个可以在任意数量的上下文中使用的通用控件,唯一的要求是组合框中的对象具有ToString() methiod,这对于进入正常组合框的对象也是一样的限制,并且由C#.NET保证。

那么,考虑到可测试性,您会在哪里放置增强功能?

1 个答案:

答案 0 :(得分:1)

与你引用的帖子一样:从gui元素中分离逻辑也是解决方案。

您应该考虑使用类似控制器的类,该类公开可以将数据绑定到ComboBox的DataSource的项目列表。控制器本身负责维护此列表。

因此,无论何时在ComboBox中键入一个字母,都可以在控制器上调用一个函数,让我们说UpdateList(string typedString)。通过这种方式,您已经将填充列表的逻辑分为“候选人”。

现在,您可以轻松编写多个测试,每个测试都使用不同的参数调用UpdateList(),然后检查项目列表。没有GUI内容需要进行测试,你只是测试算法本身。