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

Question

众所周知,TDD意味着"首先编写测试,然后编写代码".当谈到单元测试时,这很好,因为你在"单元"内是有限的.

然而,当涉及到UI时,事先编写功能测试对我来说意义不大(对我而言).这是因为功能测试必须验证(可能很长的)一组功能要求.这通常可以跨越多个屏幕(页面),前提条件如"登录","最近插入记录"等.

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

(当然,维基百科不是"权威",但这听起来很合乎逻辑.)

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

Answer 1

尝试BDD,行为驱动开发.它促进编写规范故事,然后逐步执行,激发应用程序以改变其状态并验证结果.

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

Answer 2

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

以下是由Harry Percival 撰写的" 使用Python进行测试驱动开发 "一书中提供的工作流程(可在线免费获取):

tdd工作流程

PS您可以使用例如Selenium自动执行功能测试.您可以将它们添加到持续积分循环以及单元测试中.

Answer 3

测试用户界面的关键是分离您的顾虑 - 您的用户界面的行为实际上与您的用户界面的外观不同.我们在精神上与这个斗争,所以作为一个练习,像俄罗斯方块一样的游戏,并想象从一个平台(比如PC)移植到另一个平台(网络).直觉是一切都不同 - 你必须改写一切!但实际上所有这些都是一样的:

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