行为驱动开发之三，从测试驱动开发中来
TDD的由来
测试驱动开发（Test Driven Development， TDD）的想法来自于极限编程（Extreme Programming，XP）。XP始于1999年，以测试为先为理念。因为缺少工具的支持，XP一开始不温不火，直到Junit问世，XP才得到广泛推广。坊间传言，Junit是Kent Beck和Eric Gamma两位大牛在飞机上无聊了写着玩儿弄出来的。到了03年，XP的测试优先进化成TDD，即：
● 每写一段代码之前，先写一个单元测试
● 在单元测试可以运行并失败后，编写代码
● 待到代码可以使之前的测试通过后，编码完成
● 在保持测试通过情况下，重构代码
ruby语言下TDD的例子：
我希望实现一个点，即用x，y初始化它的坐标，并且对异常值进行报错。测试为先：
classTC_Point < Test::Unit::TestCase
02 @@valid_points= [[1，2]， [0，0]]
03 @@invalid_points= [[nil，3]， [3，nil]， [1， -2]， [-1，2]， [1.5，2]， [35，5.66778]]
04 deftest_valid_point
05 @@valid_points.eachdo|point|
06 p = Point.new(point[0]， point[1])
07 assert(p.row == point[0])
08 assert(p.column == point[1])
09 end
10 end
11 deftest_invalid_point
12 @@invalid_points.eachdo|point|
13 assert_raise RuntimeErrordo
14 p = Point.new(point[0]， point[1])
15 end
16 end
17 end
18 end
该代码可以运行后，再为Point这个类写实现：
classPoint
02 attr_reader:row，:column
03 definitialize(row， column)
04 if!row.is_a?(Integer)or!column.is_a?(Integer)
05 raise"row #{row} and column #{column} must be integer"
06 end
07 ifrow<0orcolumn<0
08 raise"row #{row} and column #{column} must be >= 0"
09 end
10 @row= row
11 @column= column
12 end
13 end
此时，运行测试。通过测试。然后，对Point这段代码进行重构。重构，即保持原有代码行为不变，改善代码的可读性，独立性等。只要改善后的Point类可以通过测试，即，重构没有影响到原有功能。
TDD的进化
JUnit之后，陆续的，各种语言也都有了自己的Unit Test Framework，一时间TDD工具如雨后春笋，拔地而起。 然而，在跟风儿的大多数们熟练工具的时候，追寻更敏捷的前辈们继续向前进发了。TDD的下一步是哪里呢？更好的隔离代码（Working Effectively with legacy code），更好的测试构架（Xunit Test Patterns），这些都是锦上添花。但是，雪中送炭的出路在哪里呢？前辈们绞尽脑汁，想出两条路：
● 现有的TDD中的T，即测试用例还是太底层，到了集成层，系统层，用户层，再这么走，走不通。所以前辈们想出了另一条路，验收性测试驱动开发（Automate Acceptance Test Driven Development，AATDD），这里头比较出名的工具属Fitnesse。
● 现有的测试用例，还是不够易懂，毕竟是代码，好让它更接近自然语言。
BDD的由来
行为驱动开发（Behavior Driven development，BDD），是从第二个点子里演变而来的。继续上述例子，我希望让我的测试代码更易懂，我可以使用这样的方式：
def test_valid_point ->
2 def test_point_should_support_set_integer_to_x_and_y
3
4 def test_invalid_point ->
5 def test_point_should_raise_error_when_set_none_integer_to_x_and_y
如果使用Ruby的BDD的工具Rspec，则可以将测试代码以自然语言的方式描述为：
describe "A new point" do
02 it "should raise exception when set none integer as x or y" do
03 none_integers = [[nil， 3]， [3， nil]， [1， -2]， [-2， 1]， [1.5， 2]， [2， 1.5]]
04 none_integers.each do |ni|
05 Point.new(ni[0]， ni[1]).should raise_error()
06 end
07 end
08 it "should accept when set integer as x and y" do
09 integers = [[1， 2]， [0， 0]]
10 integers.each do |i|
11 p = Point.new(i[0]， i[1])
12 p.x.should == i[0]
13 p.y.should == i[1]
14 end
15 end
16 end
Rspec后，其他编程语言也纷纷效仿，一系列Spec工具又如雨后春笋般。但是，追寻更敏捷的前辈们，又没有停下脚步，因为Rspec依旧停留在单元测试层，即describe/it/do的里面，还是代码。为了将自然语言引入Spec，，前辈们在此基础上开发了Cucumber。
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工具。
