敏捷杂谈之TDD与BDD

　　敏捷开发有许多种方法，但不管采用任何一种，测试都是实施敏捷的基础，及时的验证代码的正确性，系统功能的健全与否，及时的反馈，及时的叫停……都是保证敏捷的基础。所以大量的快速的自动化测试，才能保证敏捷开发在快速迭代中仍然不怎么丢失软件的质量。

　　所以，在敏捷开发里一直都有一种说法叫“代码即文档”，而且测试代码也成了功能代码的使用文档。敏捷里强调的TDD(Test-driven developmenet, 测试驱动开发)，就主要体现了这种思想：根据设计编写测试-> 实现设计的功能 -> 用测试代码验证 -> 重构实现代码 -> 改善设计 -> 再次回到根据改善的设计编写测试。反复循环下去，就是TDD所倡导的流程。

　　TDD的好处：1. 能驱使系统最终的实现代码，都可以被测试代码所覆盖到，也即“每一行代码都可测”。2. 测试代码作为实现代码的正确导向，最终演变为正确系统的行为，能让整个开发过程更加高效。TDD的不足之处或者说还不够完善的地方，是对设计和测试的编写没有一个明确的方针。作为整个循环中的向导部分，如何保证根据设计编写的测试就是最终用户所期望的系统行为?如果这一部分模糊了，那么后续所有环节几乎都要受到影响。所以，再次基础上，敏捷社区又有人提出了BDD的概念，即“行为驱动开发”。

　　BDD(Behavior-driven development)把TDD中模糊的那一部分给明确了，强调开发、测试、BA、客户等所有项目相关人员都用自然语言来描述系统的行为。大家看到的描述一致，读到的内容一致，于是最终测试驱动开发产出的结果也应该是最符合用户期望的。所以在BDD的倡导下，介绍了一种简洁的类似自然语言叫Gherkin Language。下面看一个用Gherkin Language描述系统行为的例子：

　　[plain] view plaincopyprint?

　　As a xxx [Role]

　　I want to xxx [Feature]

　　So that I can xxx[Benefit]

　　Scenario 1: create user

　　Given a admin log into the system

　　when he create a user with name 'mike'

　　then mike should be able to log into the system

　　As a xxx [Role]

　　I want to xxx [Feature]

　　So that I can xxx[Benefit]

　　Scenario 1: create user

　　Given a admin log into the system

　　when he create a user with name 'mike'

　　then mike should be able to log into the system

　　随着BDD的出现和发展，使用大家都能轻易理解和认知的语言来描述系统的行为并创建User Story，TDD的反复循环的流程也就能更顺利的进行下去了。BDD的核心价值是体现在正确的对系统行为进行设计，所以它并非一种行之有效的测试方法。它强调的是系统最终的实现与用户期望的行为是一致的、验证代码实现是否符合设计目标。但是它本身并不强调对系统功能、性能以及边界值等的健全性做保证，无法像完整的测试一样发现系统的各种问题。

　　有种说法是BDD是TDD的进化，其实笔者看来，没有孰优孰劣，它们的本质和目标都是一致的。只是在实施方法上，进行了不同的探讨来完善整个敏捷开发的体系。如果BDD书写的User Story或者叫测试用例，不能作为开发、测试和客户等人共同参与和看到的一致性内容的话，那么它的价值也几乎得不到体现。另外一点，由于BDD不能代替完整的测试，旨在描述系统的行为，所以就像Gherkin Language的例子所体现的那样，关键是“简洁”，切忌啰嗦的想把每一步操作和任何情况都说得很清楚。

　　最后总结：TDD的迭代反复验证是敏捷开发的保障，但没有明确如何根据设计产生测试，并保障测试用例的质量，而BDD倡导大家都用简洁的自然语言描述系统行为的理念，恰好弥补了测试用例(即系统行为)的准确性。(不管以上理念是否先进，切忌盲从和滥用)

原文转自：http://www.ltesting.net