BDD, Behavior Driven Development 行为驱动开发 - 敏捷开发第二代浪潮

讲到中国的开发，那是非常独特的，只求达到目的，管它过程是如何的？当然不是说所有中国人的开发都是这样，只是个普遍现象。

我们需要测试么？我们需要代码规范么？如果为了可以节省时间完成目标，还管的了这么多么。真是的，老板催呢。

这里我为什么提及这个我们的硬伤呢？因为我一说TDD，估计会一部分人不清楚。因为他从来没写过一行测试代码。小项目，小成本的东东，还需要考虑这手段？哈哈，是啊，工作是很无奈，苦逼的程序员。

   好吧，我们稍微介绍一下TDD的概念，好让我更深入主题到BDD。Test Driven Development，顾名思义，测试驱动模式开发。一般的手段是，通过验证代码的结果，来验证我们的逻辑是符合真正的需求，然后进一步的实现代码。我们首先领出首先要哪些功能，然后，以此验证这些功能的是否正常工作。代码起手是从测试代码着手，然后在测试的过程完成实际的逻辑代码，这样一来，我们可以确保，我们做的事情是遵循需求的规范的。至于实现代码怎么写，怎么组织，可以是任何一种形式。非常重要的一点就在于此，强调代码质量，可靠性。

  一般测试分为最重要的两部分，单元测试与功能测试，当然还有其他类种测试需求的可能性。

   单元测试，一般的方式是针对一个类，或者一个接口，对其public部分进行逻辑测试。针对一个类的一个函数，如果我们调用它，传入所有可以例举的参数之后，能正常工作的话，我们就认为它通过了。一个类如果有几十个函数或者方法，我们就如此一一的进行测试，很琐碎厌烦的工作。如果有几十个类，那么我们也如此一一的进行测试，很恐怖的一件事情。但又如何呢？毕竟代码就是靠严谨才能正常的工作。 

  功能测试，比较针对于最终客户需求，单元测试的话，比较针对程序员自我定义，自我组织代码结构，当然程序员这么做，还是要最终完成实现客户需求。功能需求，注重系统用户的行为以及行为结果。譬如，我在某个面板上输入一些信息之后，我要得到一张报表数据，我是不会管代码是如何实现的，我只求结果是属实的。开发者需要如何组织代码结构，构建类库，书写逻辑，来完成我的这个目的。而这些类结构，程序员自己去做单元测试，那么用户最终来测试这些功能。当然，程序员在提交项目之前，不做功能测试么？NO。也做，但程序员不一定完全了解最终用户需求，所以为什么会有争执呢？你懂的。现实中，一般功能测试的人员，不是程序员，或者说是稍等程序员的测试员。他们注重理解需求，然后制定一系列的测试流程，进行一一测试，出错了，就截个图写个bug日志，最终汇总给程序员再去解决问题。

  项目往往会失败或者变成持久战，耗费许多的人力物力与时间。原因何来？单方面程序员的问题？架构师的问题？客户的问题？这里我们领出一个非常重要的因素就是：沟通。

  如果我叫你去关个灯，你完成这件事情会很简单，因为开关就两种状态，你也很懂其原理。但是我们实际的项目不是解决这么简单的需求。如果我叫你去做一件事情，你却因为时间不够，叫另外一个人来帮你做，然后呢那个人又是家里出了状况，再叫好兄弟铁哥们的去做。结果是，最后做的人，根本没有领会我的要求，因为这里面产生种种口误，措辞问题，导致我的要求为达到。回到我们的项目开发中来，你会发现，实际情况亦是如此。客户提出需求，需求再有需求分析师分析，提交文档给架构师架构，架构师组织结构，分派局部代码任务给程序员来完成，完成之后交友测试员来进行测试，测试员通过理解客户需求，进行测试反馈。我们的软件最后的发布版本才可能让最终用户进行验证。这么一来，这么多环节能不错点小叉么？如果一开始需求分析师一开始理解客户需求就是非常准确的还好，可是事实上往往并非如此。所谓叫做一错再错，导致的连锁反应就是，给个环节的争执，纠纷，责任推卸。

  好了，我们就会问，有没有一种方法，可以解决这种需求传递模式？有，人不傻，吃亏都会想办法。于是，敏捷开发模式就诞生了。强调的什么？给个地址你们 http://agilemanifesto.org/，首页的敏捷宣言就是他们的强调理念。

We are uncovering better ways of developing

software by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on

the right, we value the items on the left more.

我们一直在实践中探寻更好的软件开发方法，

身体力行的同时也帮助他人。由此我们建立了如下价值观：

个体和互动 高于 流程和工具

工作的软件 高于 详尽的文档

客户合作 高于 合同谈判

响应变化 高于 遵循计划

也就是说，尽管右项有其价值，

我们更重视左项的价值。

  虽然官方，没有更加强调核心，我的总结就是 【沟通】，一切都是为了让一群人大家能达到一致的理解，然后去做事情。即使想法有变，我们还可以在原有的共同沟通信任的基础上进行再次沟通。

  好了，说了半天，好像我所说的和我的主题没有半毛关系。因为要引入BDD的理念，我必须先阐述以上的一些内容，以便于，认识到我们为什么要用BDD模式进行项目开发。有人就会问了，我懂敏捷模式，而且实战多少年了。你问问你自己，是不是还不够理想呢？目前主流的模式采用一种实战形式，如scrum，xp等等一种敏捷开发方式。常用的项目进展驱动模式是TDD。但如我刚才所说，TDD再进行单元测试的时候比较顺手，但是遇到功能测试，会比较乏力。BDD，顾名思义，就是靠行为，行为结果，来驱动项目进展，强调客户最终需求是导航旗，我们的测试如果让他们直观的操作也好，看到结果也好，那不是里立马能验证，我们所做开发是否在正确的道路上呢！ 而不是之前，程序员写测试代码，自认为的代码没问题，最后客户需求我想也没问题的方式去做事。

 停住，你说了那么多了。都是文字，看得我的眼睛都疼了，脑子也快成浆糊了。能不能来点实际点的。行。下面，我们就来找一种语言，来实现。对，BDD和语言无关，php,java,.net都得到了实现。我们本次采用的是php语言，采用behat技术来实现BDD。