开发用户界面时TDD是否适用？

Question

在开发用户界面时，您对使用TDD有何看法和经验？

我一直在思考这个问题已有一段时间了，只是无法做出最终决定。我们即将开始一个Silverlight项目，我考虑了TDD Microsoft Silverlight Unit Test Framework，但我不确定如何将该方法应用于UI开发 - 特别是Silverlight。

修改 问题是关于将TDD用于UI开发是否实际可行，而不是关于如何分离关注点。

Answer 1

尝试测试UI组件的确切位置是没有意义的。首先是因为布局是主观的，应该由人类“测试”。其次，因为随着UI的变化，你将不断重写你的测试。

同样，除非您正在编写新组件，否则不要自行测试GUI组件。相信框架可以完成它的工作。

相反，您应该测试构成这些组件基础的行为：构成应用程序的控制器和模型。在这种情况下使用TDD可以使您分离关注点，从而使您的模型真正成为一个数据管理对象，而您的控制器确实是一个行为对象，而且它们都没有与UI紧密耦合。

Answer 2

我从UI的角度来看TDD更多来自UI的通过验收标准。在某些圈子中，这被标记为ATDD或验收测试驱动开发。

我发现使用TDD for UI的最大过度工程是我对使用自动化测试测试外观和感觉问题感到兴奋。我的建议：不要！专注于测试行为：此单击产生这些事件，此数据可用或显示（但不显示它的显示方式）。外观和感觉确实是您的独立测试团队的领域。

关键是要将精力集中在“高附加值”活动上。自动样式测试更多的是债务（使它们保持最新）而不是增值。

Answer 3

如果您将逻辑与实际的GUI代码分开，您可以轻松地使用TDD来构建逻辑，如果您需要，也可以在逻辑上构建另一个接口。

Answer 4

我无法与Microsoft Silverlight交谈，但我从未将TDD用于任何类型的布局问题，只是不值得花时间。有效的方法是使用单元测试来检查您实现的任何类型的布线，验证和UI逻辑。大多数系统为您提供对用户所采取操作的编程访问，您可以使用这些来断言您的期望是否得到了正确满足。例如。在按钮上调用click（）方法应该执行你想要的代码。在列表视图中选择项目会将所有UI元素内容更改为此项目属性...

Answer 5

根据您的编辑，这里有一些关于我们如何在当前团队中执行此操作的详细信息。我正在使用GWT编写Java，因此Silverlight的应用程序可能有点过时了。

要求或错误进入开发人员。如果有UI更改（L＆amp; F），我们会快速模拟UI更改并将其发送给产品所有者进行审批。在我们等待的同时，我们开始了TDD流程。

我们至少从Web测试开始（使用Selenium在浏览器中推动用户点击），或使用Concordion，FiT或类似的“无头”功能测试。一旦完成并失败，我们就可以高度了解攻击底层服务的位置，以使系统正常工作。

下一步是挖掘并编写一些失败的单元和集成测试（我认为单元测试是独立的，没有依赖，没有数据等。集成测试是完全连线的测试，可以读/写数据库，等）

然后，我从下往上使它工作。听起来像你的TDD背景会让你在这里推断出好处。重新上升......

Answer 6

我认为Ayende Rahien this blog post使用务实和健全的方法很好地回答了我的问题。以下是帖子中的一些引用：

  

例如，测试用户界面很常见   它不值得的地方   时间和精力。

     

...

     

代码质量，灵活性和   改变的能力是其他事情   通常归因于测试。   他们当然有所帮助，但他们是   没意思唯一（甚至是最好的）   接近那个的方法。

测试只应在为项目增加价值时使用，而不是成为主要焦点。我终于确信，使用面向用户界面的测试驱动开发很快就会成为很多不值得的工作的源头。

请注意，这篇文章似乎主要是关于测试后的事情，而不是BEFORE（如TDD） - 但我认为以下的黄金法则仍然适用：最重要的事情值得付出最大努力，不太重要的事情值得花更少的精力。拥有经过单元测试的UI通常并不重要，正如Ayende所写，使用TDD作为开发模型的好处可能不是那么大 - 特别是当你想到开发一个用户界面通常是一个自上而下的过程。

Answer 7

GUI的本质很难测试，因为Brian Rasmussen建议将对话框代码与GUI代码分开。

这是Humble Dialog Box Pattern。

例如，您可能有一个对话框，其中输入了详细信息（例如信用卡号），您需要对其进行验证。对于这种情况，您可以将用Luhn algorithm检查信用卡号的代码放入您测试的单独对象中。 （该算法只是测试数字是否合理 - 它是为检查转录错误而设计的。）

Answer 8

在我的工作场所，我们使用TDD，我们实际上是通过Apache Wicket的WicketTester对我们的UI代码（对于Web应用程序）进行单元测试，但它并未测试某些描述性标签是否位于文本字段之前或类似的东西，我们测试组件的层次结构有点正确（“标签与文本字段”在同一子集中），组件是它们应该是什么（“< em>这个标签确实是一个标签“）。

就像其他人已经说过的那样，由真人决定如何将这些组件放在UI上，而不是程序员，尤其是因为程序员倾向于使用一体化/模糊命令行工具而不是用户界面易于使用。

Answer 9

测试驱动开发更适合开发代码而不是开发用户界面。执行TDD有几种不同的方式，但真正的TDD的首选方法是首先编写测试，然后编写代码以通过测试。这是在整个开发过程中迭代完成的。

就个人而言，我不确定如何为UI执行TDD;但是，我所在的团队对我们的UI进行自动模拟测试。基本上，我们有一套模拟，每小时在最新版本的应用程序上运行。这些测试执行常见操作并验证某些元素，短语，对话框等是否基于一组用例正确发生。

当然，这确实有其缺点。这样做的缺点是模拟被锁定在代表案例的代码中。它几乎没有变化的余地，并且基本上说它希望用户对此功能做出完全这种行为。

有些测试比没有测试好，但可能更好。

Answer 10

是的，您可以使用TDD对Web应用程序的GUI测试产生很好的效果。

测试GUI时，通常使用存根/假数据，可以测试gui中所有不同的状态变化。您必须将业务逻辑与gui分开，因为在这种情况下，您将要模拟业务逻辑。

这非常适合捕捉测试人员总是忘记点击的东西;他们也会失明！