惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

The GitHub Blog
The GitHub Blog
Microsoft Azure Blog
Microsoft Azure Blog
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
V
Vulnerabilities – Threatpost
人人都是产品经理
人人都是产品经理
小众软件
小众软件
O
OpenAI News
量子位
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
C
Cyber Attacks, Cyber Crime and Cyber Security
N
Netflix TechBlog - Medium
J
Java Code Geeks
D
Darknet – Hacking Tools, Hacker News & Cyber Security
Martin Fowler
Martin Fowler
S
SegmentFault 最新的问题
I
InfoQ
V
Visual Studio Blog
C
Cisco Blogs
T
Threat Research - Cisco Blogs
K
Kaspersky official blog
CTFtime.org: upcoming CTF events
CTFtime.org: upcoming CTF events
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
Scott Helme
Scott Helme
大猫的无限游戏
大猫的无限游戏
C
Cybersecurity and Infrastructure Security Agency CISA
P
Proofpoint News Feed
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
T
The Exploit Database - CXSecurity.com
Y
Y Combinator Blog
宝玉的分享
宝玉的分享
酷 壳 – CoolShell
酷 壳 – CoolShell
T
The Blog of Author Tim Ferriss
T
Tor Project blog
Spread Privacy
Spread Privacy
T
Threatpost
S
Schneier on Security
A
Arctic Wolf
The Cloudflare Blog
cs.CL updates on arXiv.org
cs.CL updates on arXiv.org
C
CXSECURITY Database RSS Feed - CXSecurity.com
Simon Willison's Weblog
Simon Willison's Weblog
Apple Machine Learning Research
Apple Machine Learning Research
D
DataBreaches.Net
D
Docker
G
GRAHAM CLULEY
S
Securelist
P
Palo Alto Networks Blog
阮一峰的网络日志
阮一峰的网络日志
L
LINUX DO - 热门话题
P
Privacy International News Feed

博客园 - laughter

使用Using的注意事项 [转]VMPlayer的Briged网络配置 [转]移动互联网应用技术架构简介-Restful服务 理解WCF中的Contracts [翻译]在ASP.NET Web API中通过OData支持查询和分页 [转]NBehave行为驱动测试关于story和scenarios [转]使用TeamCity对项目进行可持续集成管理(一) [转]SpecFlow使用入门 [转]软件测试- 3 - Mock 和Stub的区别 [翻译]创建ASP.NET WebApi RESTful 服务(11) [翻译]创建ASP.NET WebApi RESTful 服务(10) [翻译]创建ASP.NET WebApi RESTful 服务(9) [转]模拟HttpContext 实现ASP.NET MVC 的单元测试 [翻译]创建ASP.NET WebApi RESTful 服务(8) [翻译]创建ASP.NET WebApi RESTful 服务(7) [转]软件开发过程(CMMI/RUP/XP/MSF)是与非? [转]比较 Rational Unified Process (RUP) 和 Microsoft Solutions Framework (MSF) [翻译]Behavior-Driven Development (BDD)行为驱动开发(一) 【Visual Studio2010】创建XAML分析插件
[翻译]Behavior-Driven Development (BDD)行为驱动开发(二)
laughter · 2014-04-06 · via 博客园 - laughter

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

行为驱动开发

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

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

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

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

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

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”,因为它包含了一系列以用户为中心的最佳开发实践,改变了以往技术方案为中心的方式,将用户意图当做首位。因此,将有助于创建更好的软件,实现用户的需求。

来源:http://blog.codeship.io/2013/04/22/from-tdd-to-bdd.html