TDD
TDD （Test Drvien Development）测试驱动开发，TDD 的节奏：红 - 绿 - 重构
红表示写了一个新的测试，测试还没有通过的状态；绿表示写了功能代码，测试通过的状态；而重构就是在完成基本功能之后，调整代码的过程。
先写测试，然后写代码完成功能，在第一步和第二步上，测试先行开发和测试驱动开发是一样的。二者的差别在于，测试驱动开发并没有就此打住，它还有一个更重要的环节：重构（refactoring）。
所以我们说，测试先行开发和测试驱动开发的差异就在重构上。
在测试驱动开发中，重构与测试是相辅相成的：没有测试，修改代码只能是提心吊胆；没有重构，代码的混乱程度会逐步增加，测试也会变得越来越不好写。
重构就是一个消除代码坏味道的过程。一旦你有了测试，你就可以大胆地重构了，因为任何修改错误，测试都会替你捕获到。
TDD真正动手做开发的第一步是任务分解，把一个规模很大的需求拆分成若干小任务。面对一个具体的小任务，我们才有动手写测试的基础。测试驱动开发要从任务分解开始。
为了写测试，首先“驱动”着我们把需求分解成一个一个的任务，然后会“驱动”着我们给出一个可测试的设计，而在具体的写代码阶段，又会“驱动”着我们不断改进写出来的代码。把这些内容结合起来看，我们真的是在用测试“驱动”着开发
BDD
BDD（Behavior Driven Development）行为驱动开发，BDD是从业务视角出发的，这种出发点很大程度受到领域驱动设计DDD的影响。在 BDD 的话语体系中，“测试”的概念就由“行为”所代替，所以，这种做法称之为行为驱动开发。
今天最流行的 BDD 框架应该是 Cucumber,下面是一个 BDD 的示例
Scenario: List todo item
Given todo item "foo" is added
And todo item "bar" is added
When list todo items
Then todo item "foo" should be contained
And todo item "bar" should be contained
从这个例子我们不难看出，BDD 的测试用例有很强的可读性。即便我们不熟悉技术，单凭这段文字，我们也能看出这个用例想表达的含义。这也就是我们前面说 BDD 测试用例更贴近业务的原因。它希望成为业务人员和技术团队之间沟通的桥梁，所以，它的表述方式更贴近于业务。
这里的核心点就是它的描述格式：“Given…When…Then”。Given 表示一个假设前提，When 表示具体的操作，Then 则对应着这个用例要验证的结果。
想写好 BDD 的测试用例，关键点在用业务视角描述。具体的案例可以看看https://github.com/supremecsp/geektime-todo
或者其他博客：https://cloud.tencent.com/developer/article/1478850
文章来源：极客时间《程序员的测试课》第17,18节
网友评论