关于“tdd”和“bdd”

一．定义

TDD (Test-Driven Development)：测试驱动开发是敏捷开发中一项核心的实践和技术，是一种设计方法论。
核心思想：测试驱动(先编写测试代码，通过使测试通过来推动整个开发的进行)。
TDD通常使用的是代码层级测试的工具，最常见的是xUnit家族，单元的写法没有特别的局限，一般都是调用函数，检查返回
测试驱动开发并不只是单纯的测试工作，而是把需求分析，设计，质量控制量化的过程
TDD首先考虑使用需求（对象、功能、过程、接口），主要是编写测试用例框架对功能的过程和接口进行设计，而测试框架可以持续进行验证
优点：1.能驱动系统最终的实现代码都可以被测试代码所覆盖到，即每一行代码都是可测的。2.测试代码座位实现代码的正确导向，最终演变成正确的系统行为，能让整个开发过程更高效。
缺点：对设计和测试的编写没有一个明确的方针。作为整个循环中的向导部分，如何保证设计编写的测试就是用户期待的最终行为？

BDD (Behavior Driven Development)：行为驱动开发是一种敏捷软件开发的技术。BDD的核心价值是体现在正确的对系统行为进行设计，所以它并非是一种行之有效的测试方法

核心思想：BDD的核心是设计，主要是从用户的需求出发，强调系统行为
BDD通常以类为单位，关注一个类是否实现了文档定义的行为
BDD 有非常有辨识力的行为测试用例格式（GWT）结构。
优点：
1.可以成为设计的一部分，在设计一个类的时候，一般会先写这个类需要实现哪些功能，然后逐个实现需求。
2. 使用一个句子来描述要测试的行为，而不是简单的重复被测试的接口名。
3.支持文档自动化。
4.表述更接近自然语言的习惯。

二．TDD和BDD的联系和区别：

所以说，TDD、BDD根本不是一个层面的东西，解决的是不同的问题。但BDD、ATDD、SBE基本上都认为TDD是基础，也即是说，他们主张做BDD、ATDD、SBE必做TDD。但反之则未必。

三．实践及问题：

1. 流程问题：

正确流程：先写BDD的scenario -> 再写单元测试 -> 写代码让单元测试通过 ->让BDD的scenario通过

可能会出现的问题：当开发时间很紧的时候，开发很容易会先写代码，再补TDD测试，再补BDD测试

2. 自动化框架稳定性问题：

测试有可能会随机挂
测试跑的时间过长
维护成本问题
测试覆盖率的要求
有一些场景不是很适合BDD（比如单纯UI测试，一些数据经常变化的scenario）