用于具有功能测试的用户界面（UI）的测试驱动开发（TDD）

Question

众所周知，TDD意味着“首先编写测试，然后编写代码”。当谈到单元测试时，这很好，因为你受限于“单位”。

然而，当谈到UI时，事先编写功能性测试对我来说意义不大（对我而言）。这是因为功能测试必须验证（可能很长的）一组功能要求。这通常可能跨越多个屏幕（页面），前提条件如“登录”，“最近插入记录”等。

According to Wikipedia:

  

在需要完整功能测试来确定成功或失败的情况下，测试驱动开发很难使用。这些示例包括用户界面，与数据库一起使用的程序，以及一些依赖于特定网络配置的程序。

（当然，维基百科不是“权威”，但这听起来很合乎逻辑。）

所以，任何想法，或更好的体验，功能测试 - 首先是UI，然后是代码。它有用吗？它是“疼痛”吗？

Answer 1

试试BDD, Behavior Driven Development。它促进编写规范故事，然后逐步执行，刺激应用程序改变状态并验证结果。

我使用BDD场景来编写UI代码。使用BDD故事描述业务请求，然后编写功能以转换故事，即测试绿色。

Answer 2

功能测试的TDD对我来说很有意义。编写一个功能测试，看它失败，然后将问题分成几部分，为每个部分编写单元测试，为每个部分编写代码，参见单元测试通过，然后你的功能测试应该通过。

以下是Harry Percival在书中Test-Driven Development with Python建议的工作流程（可在线免费获取）：

P.S。您可以使用例如自动化功能测试。硒。您可以将它们添加到持续积分循环以及单元测试中。

Answer 3

测试用户界面的关键是separate your concerns - 用户界面的行为实际上与用户界面的外观不同。我们在精神上与这个斗争，所以作为一个练习，像俄罗斯方块一样的游戏，并想象从一个平台（比如PC）移植到另一个平台（网络）。直觉是一切都不同 - 你必须改写一切！但实际上所有这些都是一样的：

• 游戏规则。
• 块的速度下降。
• 行匹配的逻辑
• 选择了哪个区块
• 还有更多......

你明白了。唯一改变的是如何绘制屏幕。因此，将UI的外观与其工作原理分开。这很棘手，通常不会很完美，但它很接近。我的建议是最后编写UI。如果您的行为正常，测试将提供反馈，屏幕将告知它是否正确。这种组合提供了我们在没有UI的情况下从TDD中寻找的快速反馈。

Answer 4

如果您希望自己的UI能够达到预期效果，那么程序化UI测试就是一种拯救。 UI测试更接近BDD（行为驱动开发）而不是TDD。但术语是阴天，但你称之为'em他们是有用的！ 我使用cucumber获得了相当不错的经验。我用它来测试flex应用程序，但它主要用于测试Web应用程序。点击链接！该网站有很好的方法论例子。

Answer 5

如果您非常了解UI的行为方式，并且确保您预先构建的功能测试的更改成本较低，那么ATDD非常有用。

当然，这样做的最大问题通常是UI没有完全用完。

例如，如果您正在构建产品，并且仍在进行快速迭代以获得通过可用性测试并包含反馈的UI，那么您不希望通过每次小的更改来修复功能测试的包袱用户界面。

鉴于功能测试通常很慢，反馈周期很高，并且随着UI的变化使它们保持绿色非常痛苦。

我在一个产品团队工作，我们做出了同样的决定。我的一位同事很好地总结了我们的最终方法here。 （免责声明：请忽略那里的工具具体细节。）

Answer 6

我已经使用UI完成了Acceptance TDD。我们断言通过xpath'ing使用公共页眉和页脚来获取适当的ID。我们还使用xpath来断言相对于我们用于基本布局和结构的任何ID，出现在正确标签中的数据。我们还断言输出页面是有效的html 4.01严格。

Answer 7

尝试将BDD与TDD结合使用。

• BDD将场景定义为与gui（尚未实现）的交互
• 虽然有“未实施BDD-Step”（灰色或红色）
  • 将当前scenarion的一些未实现的BDD-Step转换为运行代码
  • 使用tdd
  实施此步骤

有关详细信息，请参阅MSDN-Article Behavior-Driven Development with SpecFlow and WatiN。尽管文章是关于asp.net的，但背后的想法是普遍的。