行为驱动开发之三，从测试驱动开发中来
测试驱动开发（Test Driven Development, TDD)的想法来自于极限编程（
Extreme Programming，XP)。XP始于1999年，以测试为先为理念。XP一开始不温不火，可后来有了Junit，一下子就家喻户晓了。坊间传言，Junit是Kent Beck和Eric Gamma两位大牛在飞机上无聊了写着玩儿弄出来的。当然，倘是在中国春运的慢车上写的，那敬仰他们的人会更多。有了Junit，原来XP的理念才可以有的放矢。到了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类可以通过测试，即，重构没有影响到原有功能。
JUnit之后，陆续的，各种语言也都有了自己的Unit Test Framework，一时间TDD工具如雨后春笋，拔地而起。 然而，在跟风儿的大多数们熟练工具的时候，追寻更敏捷的前辈们继续向前进发了。TDD的下一步是哪里呢？更好的隔离代码(Working Effectively with legacy code)，更好的测试构架（Xunit Test Patterns)，这些都是锦上添花。（当然，这两本也确实是好书，对TDD有兴趣的不该错过。）
但是，雪中送炭的出路在哪里呢？前辈们绞尽脑汁，想出两条路：
- 现有的TDD中的T，即测试用例还是太底层，到了集成层，系统层，用户层，再这么走，走不通。所以前辈们想出了另一条路，验收性测试驱动开发（Automate Acceptance Test Driven Development, AATDD)，这里头比较出名的工具属Fitnesse。
- 现有的测试用例，还是不够易懂，毕竟是代码，最好让它更接近自然语言。
行为驱动开发（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的里面，还是代码。于是，前辈们在此基础上开发了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中，开发人员的意愿
- 测试人员的编码技能
- 项目所用技术