上篇文章我们聊到了测试驱动开发（TDD-Test Driven Development），这篇文章我们接着来聊聊行为驱动开发（BDD-Behavior Driven Development）。
其实客户和开发人员在需求的沟通上，多数情况下沟通是有一些不同步的。假设客户能够看懂代码，那客户就能够直接了解他的需求有没有实现了。但是往往客户并不懂代码，所以说让客户来看TDD的代码，那肯定是看不懂的，这就造成了需求交流的障碍。
但是有了BDD就不一样了。BDD将自然语言按照一些简单的语法组织起来，这样即使不懂编程的人员也能看得懂了，代码将会变得非常容易解释和理解。使用BDD可以让非技术人员、客户都可以参与到需求的确认和验收当中。
例子一：
Scenario: Refunded items should be returned to stock
Given a customer bought a black sweater from me
and I have three black sweaters left in stock.
When he returns the sweater for a refund
then I should have four black sweaters in stock.
例子二：
场景：微信聊天
假如 手机安装了微信
当 用户打开微信
那么 手机会出现用户的微信聊天界面
例子一中就是BDD使用的语言Gherkin，它的理念就是使用自然语言来描述功能，而且强调的是例子来说明需求功能。说白了，就是把代码要实现的功能用大家都能看懂的语言写出来。
市面上也有很好的BDD工具，比如Cucumber和SpecFlow，通常常用于自动验证特征文件（使用Gherkin编写的）中定义的行为。这些BDD工具解析特征文件中的行为，并执行“胶水代码”，“胶水代码”的作用就是将特征文件中的行为映射到执行步骤，这些执行步骤通常是Java或者.NET代码。因此，测试人员可以使用特征文件作为测试用例，来验证与需求相关的行为。
其实上面也提到了BDD的一些优势，但是并不全面，这里系统地梳理一下BDD给软件开发带来了几个优势:
-
增强协作: BDD为团队中的不同职位角色提供了一种通用语言。这有助于技术和非技术团队成员理解项目的预期功能和业务需求。
-
利用更广泛的领域专业知识。因为行为是以人类可以理解的格式定义的，团队可以利用测试人员、架构师和其他持有不同观点的人的专业知识。
-
以测试为重点满足需求。BDD驱动测试覆盖率，关注满足需求。这与TDD侧重于验证编译单元不同。
-
降低成本和风险。BDD提高了软件开发结果的可预测性，这减少了返工和后期代码破坏。
-
促进重用并降低自动化的复杂性。编写“胶水代码”的开发人员通常是编写可重用的测试步骤的不二人选。例如，一个应用程序可能有一些重复的设置步骤，需要调用这些步骤来实现某个状态。开发人员可以在“胶水代码”中定义这些步骤，“胶水代码”可以被重用来处理设置和执行。
虽然BDD有诸多好处，但是BDD的实施也是需要一定的成本的，编写“胶水代码”就需要花费了相当大的成本。在绝大多数情况下，这项任务都是开发团队负责的。
在BDD出现之前，测试人员都是使用工具或者框架来验证功能的测试，但这些测试不一定是针对需求的。但是使用BDD后，测试人员、业务分析师和其他关系的人在一个特征文件中定义行为，但是开发人员仍然需要编写将这些行为映射到执行步骤的“胶水代码”。
BDD的这步工作增加了开发的成本，这一点也大大阻碍了很多团队使用BDD。当然了，“胶水代码”的宗旨在于可重用，并且可以应用到自动化流程中。但是往往在企业中去实现BDD，这个投资通常都是相对较高的。那我们有没有办法去减少成本呢？
在一定程度上，Cucumber、SpecFlow和其他BDD引擎推动一些团队去使用BDD，但是它们没有解决资源限制、易用性和其他挑战等问题。这就是Parasoft SOAtest可以起到作用的地方。SOAtest是一个API和UI功能测试解决方案，它可以跨多个接口和各种端点自动执行端到端测试场景。
SOAtest通过使用一个更简单的方法(使用无脚本的测试自动化UI来定义可重用的测试用例)代替编写“胶水代码”的繁重任务，降低了使用BDD的成本。通过使用SOAtest来定义“胶水代码”,测试人员和业务分析师能够在特征文件中定义行为，这让团队能够将更多的资源分配到软件的具体细节上。
BDD和TDD都是软件开发阶段的概念，他们有着很多相似的地方，正是因为这种相似性和细微差别，其实很多人都觉得BDD是TDD升级版。其实不然，这两种方法的目的在于解决不同的问题，两者的着重点不同，并且两种方法互补才是最好的方案，彼此作为另一方实践不足的补充。
TDD工作的产物就是单元测试，它保证了我们的代码质量。TDD的目的从来不在于验证需求是否实现，这就是为什么团队只采用BDD也会有比较好的效果，因为只采用的BDD的项目都是在很大程度上完成了需求实现。BDD关注的不是测试，而是预期的行为。利用TDD来编写高质量的代码，使用BDD来确保代码实现预期需求。
每种方法都有优点和局限性，但是Parasoft可以帮助任何团队降低同时采用TDD和BDD的成本。SOAtest用一个更简单的测试用例创建接口取代了繁琐而昂贵的“胶水代码”的编写过程，这使得BDD也更加容易实现。Jtest的引导性测试创建功能不仅能生成更好的测试、更多可测试的代码和更高的覆盖率，还能减少创建单元测试的时间。
TDD和BDD有效协作能够帮助团队在软件开发过程中创造竞争优势，而Parasoft可以帮助团队更快、更可靠地创造竞争优势。
（滑动查看更多内容）
