不要再用BDD了

某公司遇到的困境

之前在某公司咨询的时候，遇到了这种场景，公司想做敏捷转型，然后自己找了很多敏捷相关的实践，这其中就包含BDD。 由于之前公司之前并没有自动化的测试，所以在讨论自动化的实施的时候，听说BDD这个敏捷实践很不错，就专门花重金找了一个测试专家搭建了一套BDD的测试框架。 然后同样又花重金请人教会了他们测试人员如何去运用这套BDD框架写自动化测试用例，甚至从外面招聘有BDD自动化经验的人。做完了所有的准备工作之后，大家对产品瞬间就有信心了，于是就开始了他们BDD之旅。

做法很简单，就是开发去做卡，做完之后就交给测试去测试，最后由测试去写BDD的测试。所有的BDD的测试都是端到端的测试，大家做了很多这种端到端的自动化测试，随着时间的推移，这种自动化越来越多，大家发现好像BDD的测试框架好像并没有像预期的那样发现很多问题，帮助他们改善质量。相反的，维护这些测试用例却花费了大量的时间。由于BDD是公司的领导层想推行的实践，大家也不好去反对。慢慢的BDD变成了一种形式，花了很多时间去写，但是却没有达到预期的效果。  

问题出在哪？

我们在尝试运用某个敏捷方法的时候，至少需要想考虑清楚两方面，第一个是这个敏捷方法的使用场景，第二个是这个敏捷方法能够带来哪些价值。

BDD的概念

基于上面所提出的问题，我们首先来看下一下BDD的概念： 

Behavior-Driven Development (BDD) is a set of software engineering practices designed to help teams build and deliver more valuable, higher quality software faster. It draws on Agile and lean practices including, in particular, Test-Driven Development (TDD) and Domain-Driven Design (DDD). But most importantly, BDD provides a common language based on simple, structured sentences expressed in English (or in the native language of the stakeholders) that facilitate communication between project team members and business stakeholders.

从这中间我们可以提炼出一下几个关键点：1）行为驱动开发是一个软件工程的实践，能够帮助团队快速构建和交付更多价值和质量的软件产品。   2）BDD提供了一种通用的，简单的，结构化的描述语言，能够很方便让项目成员和业务干系人非常顺畅的沟通需求。

从中我们可以看到BDD的价值在于能够沟通与协作，能够把利益关系人、交付团队等不同方面的项目相关人员集中到一起，形成共同的理解，共同的价值观以及共同的期望值。这个是BDD的价值所在。

BDD到底应该怎样解读

那接下来我们来分析下BDD到底适合什么样的场景呢？ 我们可以从他的价值来进行分析，如果利益关系人沟通完全没有障碍，那根本不需要运用BDD，这很容易理解，比如简单的一次性的项目，或者业务比较轻量，重在技术方面的项目，大可不必运用BDD，因为在这种项目下，项目关系人对整个项目也不会存在理解上的问题。相反的，业务复杂、团队成员较多的项目，沟通成本高，BDD有可能就很有必要。

还有一个误区，上面的例子也提到了，把BDD当成仅仅是测试相关的。其实BDD并只是关于测试，它是一个敏捷方法，是一种协作方式，更多的BDD应该关注的是业务也不是技术。我们可以用以下的图来表示

另外一个很大的误区在上面例子中也有所体现，在实施的时候他们仅仅只是把BDD定义为端到端的自动化测试，这个是完全不对的，BDD的自动化可以是端到端的自动化，可以是API测试，可以是单元测试，甚至可以是他们的结合体，比如在BDD的设计中，用API去创建数据，然后再写端到端的测试。

其实对于敏捷来说，不管我们运用哪些时间，BDD？TDD？Code Review? 还是别的，我们需要基于这些具体的实践，去分析这些实践能给我们带来哪些价值。不能盲目的用。

如果通过分析发现BDD对于项目没有价值，那么勇敢的提出来，“不要再用BDD了” 。

具体BDD应该怎样正确的去做，我在以后的里面会提到，这里就不再累赘了。