Cucumber原本作为Rspec一种新的表示方式而被开发出来，但由于其语法Given/When/Then的强大，使它足可以独当一面。它可以描述包括，需求，系统设计，和模块设计等所有行为，即它可以作为自动化验收性测试，自动化系统测试，和自动化集成测试的脚本。至此，如同Junit为XP/TDD带来了春天一般，Cucumber来了，BDD的春天也来了。使用Cucumber，上述例子可以描述为：

　　有了Cucumber之后，BDD的定义总算可以有的放矢了：

　　● 以TDD为基础，加强了对自然语言的支持

　　● 可以由外而内的开发，即先写需求-用户行为，再写系统行为，再写模块行为，然后编写代码，这代码应该一路Pass单元测试，模块测试，系统测试，用户测试，这样，一个可以交付的软件就产生了

　　● 高度自动化，从外到里，都自动化了

　　● 多参与人协同工作，自然语言使得客户，测试人员，开发人员都可以参与进来

　　TDD，还是BDD

　　在采用TDD或BDD前，请先考虑一下因素：

　　● TDD中，开发人员的意愿

　　我组里头TDD说了3年，现在据我所知，看完TDD两本名著，并坚持写单元测试的人只有一个（我组里开发人员15人）。如果做TDD，那么写单元测试和代码是一起进行的，在此过程中测试人员能够参与其中的机会不多。那么由测试人员推广的TDD就变成了测试人员瞎吆喝，开发人员翻白眼。所以，如果从测试人员的角度去推广TDD，除非有老板大力支持，否则不可行（甚至有人跟我说，开发都TDD了，还要测试干嘛）。当然，如果你的开发人员都很主动好学，则另当别论。

　　● 测试人员的编码技能

　　如果测试人员推广BDD，过程就顺利些。因为在编写需求，系统行为，模块行为的过程中，开发人员可以和测试人员一起工作，提高了协同工作的时间，而不是开发人员自己单方面的努力。但是行为文档生成后，后面还需要一些代码，才能让文档成为可以运行的程序，这就对测试人员有一些编写代码的能力的要求。对于一直手动测试，从来没写过代码的测试人员，可能投入就要大些，进展就缓慢些。

　　● 项目所用技术

　　如果选择TDD，那么自然是开发用什么语言，单元测试就用什么，基本没有选择。BDD稍微灵活些，只要你的产品接口可以被BDD工具调用，就可以使用该工具。如我组内使用Java开发，程序提供了Web接口，数据库接口和命令行接口，使用Cucumber/Ruby都可以很容易调用，所以暂时不需要一定使用Java的BDD工具。

相关链接：

行为驱动开发之一，推广篇

行为驱动开发之二，实施篇