行为驱动开发之三，从测试驱动开发中来
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初始化它的坐标，并且对异常值进行报错。 测试为先：
class TC_Point < Test::Unit::TestCase
@@valid_points = [[1, 2], [0, 0]]
@@invalid_points = [[nil, 3], [3, nil], [1, -2], [-1, 2], [1.5, 2], [35, 5.66778]]
def test_valid_point
@@valid_points.each do |point|
p = Point.new(point[0], point[1])
assert(p.row == point[0])
assert(p.column == point[1])
end
end
def test_invalid_point
@@invalid_points.each do |point|
assert_raise RuntimeError do
p = Point.new(point[0], point[1])
end
end
end
end
该代码可以运行后，再为Point这个类写实现：
class Point
attr_reader :row, :column
def initialize(row, column)
if !row.is_a?(Integer) or !column.is_a?(Integer)
raise "row #{row} and column #{column} must be integer"
end
if row<0 or column<0
raise "row #{row} and column #{column} must be >= 0"
end
@row = row
@column = column
end
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 -> def test_point_should_support_set_integer_to_x_and_y def test_invalid_point -> def test_point_should_raise_error_when_set_none_integer_to_x_and_y
如果使用Ruby的BDD的工具Rspec，则可以将测试代码以自然语言的方式描述为：
describe "A new point" do
it "should raise exception when set none integer as x or y" do
none_integers = [[nil, 3], [3, nil], [1, -2], [-2, 1], [1.5, 2], [2, 1.5]]
none_integers.each do |ni|
Point.new(ni[0], ni[1]).should raise_error()
end
end
it "should accept when set integer as x and y" do
integers = [[1, 2], [0, 0]]
integers.each do |i|
p = Point.new(i[0], i[1])
p.x.should == i[0]
p.y.should == i[1]
end
end
end
Rspec后，其他编程语言也纷纷效仿，一系列Spec工具又如雨后春笋般。但是，追寻更敏捷的前辈们，又没有停下脚步，因为Rspec依旧停留在单元测试层，即describe/it/do的里面，还是代码。为了将自然语言引入Spec，，前辈们在此基础上开发了Cucumber。
Cucumber原本作为Rspec一种新的表示方式而被开发出来，但由于其语法Given/When/Then的强大，使它足可以独当一面。它可以描述包括，需求，系统设计，和模块设计等所有行为，即它可以作为自动化验收性测试，自动化系统测试，和自动化集成测试的脚本。至此，如同Junit为XP/TDD带来了春天一般，Cucumber来了，BDD的春天也来了。使用Cucumber，上述例子可以描述为：
Scenario: valid pairs Given a pair of integers "<x>" and "<y>" When I initialize a Point with it Then a point should be generated Examples: |x | y | |3 | 1| |0 | 0| Scenario: invalid pairs Given a pair of none integers "<x>" and "<y>" When I initialize a Point with it Then a point should raise exception Examples: |x |y | |nil |3 | |3 |nil | |0.1|1 | |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工具。
