[翻译]Behavior-Driven Development (BDD)行为驱动开发（二）_项目管理_非技术区_程序员俱乐部

测试驱动开发体现了开发人员对软件产品各部分运作方式的理解，而行为驱动开发则关注于开发人员对软件产品最终表现的行为的预期。

行为驱动开发

TDD更像是一种范式而不是一个过程。它描述了一种先编写测试，然后实现，并伴随可能的代码重构这样的一系列步骤。但其并没有关于以下的内容：

• 应该从哪里开始开发；
• 应该对什么进行测试；
• 测试应该怎样组织和命名。

测试驱动开发这个命名也让人疑惑，人怎么能够对不存在的东西进行测试呢。
Dan North对这些问题进行了研究，建议开发人员更应该考虑关注软件的特征行为而不是编写测试。

如果开发是行为驱动的，开发应该从对用户最重要的部分功能开始。可以看做放下开发者的帽子，而戴上用户的帽子，从用户的角度思考。实际上，分情况下，最难的部分也在此处，很多时候，你无法知道用户最关注的最重要的行为特性。但是，经过实践和多次的迭代，这一过程终将变得透明和有效。

那么接下来应该怎么表现行为了，一个基于Test::Unit的测试可能是这样的：

class="csharpcode">class UserTest < Test::Unit::TestCase
  def test_name_set
    user = User.new "Audrey"
    assert_equal(user.name, "Audrey")
  end
end

代码可以工作，但有一些缺陷：

1. 代码中有多处Test，我们需要用具体的需求来替代；
2. 语法难懂；
3. 无法明白这段代码到底要测试什么内容。

在BDD中，行为应该随处可见，如下面的红色内容：

describe User do
  it "lets me assign a name" do
    user = User.new "Paul"
    user.name.should == "Paul"
  end
end

这段测试代码的价值在于：

1. 关注点：针对于具体的行为进行测试和编码；
2. 文档：通过读以上语句，你的同事可以直接理解行为的内容，甚至不需要读代码；
3. 回归：当你之后运行所有的特性时，这就是回归测试。如果出现了问题，你很快就可以看到那个行为出错。

尽管测试语法对软件的功能行为特性做了描述，它需要一些工作来表明用户的意图。Dan North认为，可以通过定义一个模板通过自然语言来描述这些特性：

Story: Returns go to stock
In order to keep track of stock
As a store owner I want to add items back to stock when they're returned

Scenario 1: Refunded items should be returned to stock
Given a customer previously bought a black sweater from me
And I currently have three black sweaters left in stock
When he returns the sweater for a refund
Then I should have four black sweaters in stock

Scenario 2: Replaced items should be returned to stock
Given that a customer buys a blue garment
And I have two blue garments in stock
And three black garments in stock.
When he returns the garment for a replacement in black,
Then I should have three blue garments in stock
And two black garments in stock

每一个故事都有一个标题和简短的描述。描述的格式一般包括：

• 为了去实现……
• 对于你正在开发的……
• 我希望功能是这样的……

描述通过还附有一系列包含了给定步骤的场景，包含前置事件，用例行为，后置事件等。

由于BDD一直期望从用户最关注的行为开始，应该坚持以下准则：

• 找出最重要的特性；
• 在此基础上找出最重要的场景。

藉此，你可以一直站在用户需求的角度进行开发，并关注于真正有效的目标。

结论

很多人将BDD看做是“正确的TDD”，因为它包含了一系列以用户为中心的最佳开发实践，改变了以往技术方案为中心的方式，将用户意图当做首位。因此，将有助于创建更好的软件，实现用户的需求。