为什么用BDD？

What BDD？

behavior driven development 行为驱动开发

Where BDD from？

敏捷开发模式中推崇TDD（test driven development），即先测试，后编码。
落地到实践中包含两部分：
1、UTDD单元测试驱动开发（unit test driven development）
UTDD需要开发在coding需求代码前先完成测试类的编码
2、ATDD验收测试驱动开发
ATDD将验收标准不断细化，直至列出每个场景明确的输入输出

Why BDD？

UTDD对研发而言推行难度较大，既有心理障碍，也有公司成本核算的阻碍。
ATDD无以上阻碍。

假想一下，产品提供的prd中有明确的关于每一个功能点的场景说明，此时开发coding是否更简单？测试写用例是否更简单？

现实是产品提供的需求不会细化到如此，通常是测试在撰写测试用例过程中完成需求细化成每一个明确输入输出的场景。
所以我们在落地过程中是推行测试先行，测试必须在开发开始coding之前提交验收标准，也即测试用例。开发、产品、测试共同review此验收标准，理解达成一致方可开始coding。

ATDD落地的过程中就产生了BDD

BDD通常为GWT格式，Given When Then。翻译成中文即：当****，如果***，则****
与测试用例的风格神似。测试用例先提交，开发coding期间，测试能够按照GWT编写自动化测试用例，这样的用例也简单易懂。既方便后期维护，也方便人员交接。So why not？

为何推崇测试先行？

测试能够尽可能地将需求明确化，明确至每一个用例，涉及每一个正常和异常场景。如果开发在coding前能了解到每一个功能涉及到哪些异常场景，coding时就能合理规划；反之，如果开发考虑不全，coding时势必会遗漏很多场景，导致代码缺陷。这些缺陷放在后期发现，无疑提高了整个研发成本。