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

Scenario: valid pairs  

02   Given a pair of integers "" and "" 

03   When I initialize a Point with it  

04   Then a point should be generated  

05       

06   Examples:  

07     |x | y |  

08     |3 | 1|  

09     |0 | 0|  

10   

11 Scenario: invalid pairs  

12   Given a pair of none integers "" and "" 

13   When I initialize a Point with it  

14   Then a point should raise exception  

15       

16   Examples:  

17     |x |y | 

18     |nil |3 | 

19     |3 |nil | 

20     |0.1|1 | 

21     |1 |0.1| 
 


　　有了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工具。