众所周知，TDD 的意思是“先写测试，再写代码”。当涉及到单元测试时，这很好，因为你被限制在“单元”内。
但是，在 UI 方面，事先编写功能测试就没那么有意义了（对我来说）。这是因为功能测试必须验证一组（可能很长）功能需求。这通常可能跨越多个屏幕（页面），前提条件如“登录”、“最近插入了一条记录”等。
测试驱动开发很难用于需要完整功能测试来确定成功或失败的情况。这些示例包括用户界面、与数据库一起使用的程序，以及一些依赖于特定网络配置的程序。
（当然，维基百科不是“权威”，但这听起来很合乎逻辑。）
所以，任何想法，或者更好的经验，首先是 UI 的功能测试，然后是代码。它有效吗？是“痛”吗？
【问题讨论】：
标签： unit-testing tdd functional-testing
试试BDD, Behavior Driven Development。它促进编写规范故事，然后逐步执行这些故事来刺激应用程序更改其状态并验证结果。
我使用 BDD 场景来编写 UI 代码。使用 BDD 故事描述业务请求，然后编写功能以将故事变为绿色。
【讨论】：
测试 UI 的关键是 separate your concerns - UI 的行为实际上与 UI 的外观不同。我们在精神上为此苦苦挣扎，因此以俄罗斯方块之类的游戏为练习，并想象将其从一个平台（例如 PC）移植到另一个平台（网络）。直觉是一切都不一样——你必须重写一切！但实际上这一切都是一样的：
你明白了。唯一改变的是屏幕的绘制方式。因此，将您的 UI 外观与其工作方式分开。这很棘手，通常不可能完美，但很接近。我的建议是最后编写 UI。如果您的行为正常，测试将提供反馈，并且屏幕会告诉您它是否正确。这种组合提供了我们在没有 UI 的情况下从 TDD 中寻找的快速反馈。
【讨论】：
用于功能测试的 TDD 对我来说很有意义。编写一个功能测试，看到它失败，然后将问题分成几部分，为每个部分编写一个单元测试，为每个部分编写代码，看到单元测试通过，然后你的功能测试应该通过。
这是 Harry Percival 的书 Test-Driven Development with Python 中建议的工作流程（可在线免费获得）：
附：您可以使用例如自动化您的功能测试硒。您可以将它们添加到持续集成周期以及单元测试中。
【讨论】：
如果您非常了解 UI 的行为方式并确保您预先构建的功能测试的更改成本较低，那么 ATDD 将非常有用。
当然，这样做的最大问题是 UI 通常没有完全指定。
例如，如果您正在构建一个产品，并且仍在进行快速迭代以获取通过可用性测试和整合反馈的 UI，那么您不希望通过每次小的更改来修复功能测试的包袱用户界面。
鉴于功能测试通常很慢，反馈周期很长，并且随着 UI 的更改而使它们保持绿色是非常痛苦的。
我在一个产品团队工作，我们要做出完全相同的决定。我的一位同事很好地总结了我们的最终方法here。 （免责声明：请忽略该工具的具体细节。）
【讨论】：
我已经使用 UI 完成了验收 TDD。我们将通过 xpath'ing 断言公共页眉和页脚用于适当的 id。我们还使用 xpath 来断言数据出现在相对于我们用于基本布局和结构的任何 id 的正确标签中。我们还会断言输出页面是有效的 html 4.01 strict。
【讨论】：
当您想要确信您的 UI 符合预期时，程序化 UI 测试是一种拯救。 UI 测试更接近于 BDD（行为驱动开发）而不是 TDD。但是术语是多云的，无论您如何称呼它们，它们都是有用的！ 我使用cucumber 获得了相当不错的经验。我用它来测试弹性应用程序，但它主要用于测试网络应用程序。点击链接！该网站提供了非常好的方法示例。
【讨论】：