TDD概念

TDD(Test-Driven Development) “测试驱动开发".
是敏捷开发中的一项核心实践和技术、是一种方法论。思路是通过测试来推进整个开发的进行。表现为测试代码优先于业务代码。
TDD有别于以往的“先编码、后测试”的开发过程，而是在编程之前，先写测试脚本或设计测试用例。TDD在敏捷开发模式中被称之为“测试优先的编程（test-first programming）”，

TDD具体实施过程，可以看作两个层次

UTDD

在代码层次，在编码之前写测试脚本，可以称为单元测试驱动开发（Unit Test Driven Development，UTDD）
ATDD

在业务层次，在需求分析时就确定需求（如用户故事）的验收标准，即验收测试驱动开发（Acceptance Test DrivenDevelopment，ATDD）

UTDD

UTDD核心可看做一个闭环：RED -> GREEN -> REFACTOR，即运行一个失败的测试 -> 让测试通过 -> 及时重构代码。

为什么要 UTDD?

传统编码方式

需求分析，想不清楚细节，管他呢，先开始写

发现需求细节不明确，去跟业务人员确认

确认好几次终于写完所有逻辑

运行起来测试一下，靠，果然不工作，调试

调试好久终于工作了

转测试，QA 测出 bug，debug，打补丁

终于，代码可以工作了

一看代码超级烂，不敢动，动了还得手工测试，还得让 QA 测试，还得加班…

UTDD 编码方式

先分解任务，分离关注点

列 Example，用实例化需求，澄清需求细节

写测试，只关注需求，程序的输入输出，不关心中间过程

写实现，不考虑别的需求，用最简单的方式满足当前这个小需求即可

重构，用手法消除代码里的坏味道

写完，手动测试一下，基本没什么问题，有问题补个用例，修复

转测试，小问题，补用例，修复

代码整洁且用例齐全，信心满满地提交

UTDD 的好处

自解性：测试代码即文档，新接触代码的开发人员通过阅读测试代码即可充分了解业务。
健壮性：业务建立在一个个单元测试的保护之下，规避了大批bug。
正确性：修改已有代码不再烫手，测试带来了正确性保护，这将在重构或者维护时体现。
改进API：测试自然的让开发人员变得从客户端角度编写可测试的OO代码，驱动了API的设计。

他的引入也是有代价和风险的：

开发成本：开发人员需要编写测试代码。
维护成本：开发人员需要维护测试代码。
环境搭建：测试环境的建立成本。

UTDD实现步骤

先写测试代码，并执行，得到失败结果
写实现代码让测试通过
重构代码，并保证测试通过。
反复实行这个步骤测试失败 -> 测试成功 -> 重构

案例:

业务需求:

比如我们要写实现一个功能，当输入值大于等于0时返回true，当输入值小于0时返回false。

1. 先写测试代码，并执行，得到失败结果

import org.junit.jupiter.api.Test;public class Test02 {@Testpublic void test01(){// givenint input = 1;// whenboolean result = Equal01(input);// thenassert result: "测试不通过";System.out.println("测试通过,参数大于0");}private boolean Equal01(int input) {return  false;}}

2. 写实现代码让测试通过

先不管任何设计啥的，只要让测试过了就行，随便乱写。比如下面的的代码。

3. 重构代码，并保证测试通过。


public class Test02 {@Testpublic void test01(){// givenint input = -1;// whenboolean result = Equal01(input);// thenassert result: "测试不通过";System.out.println("测试通过,参数大于0");}private boolean Equal01(int input) {if(input >= 0){return true;}return false;}
}

UTDD 规则

除非是为了使一个失败的 unit test 通过，否则不允许编写任何产品代码
在一个单元测试中，只允许编写刚好能够导致失败的内容（编译错误也算失败）
只在测试全部通过的前提下重构或开始新的功能

ATDD

在业务层次，在需求分析时就确定需求（如用户故事）的验收标准，即验收测试驱动开发（Acceptance Test DrivenDevelopment，ATDD）

BDD-行为驱动开发

从ATDD演化出来一种具体落地的开发模式就是BDD（Behavior Driven Development，行为驱动开发）。BDD只是将验收标准更加明确化，可以看作是ATDD的实例化，即列出用户故事所可能遇到的应用场景，而且将这种应用场景的表达方式规定为GWT格式，

RBE-需求实例化

BDD再往前推进一步，就是需求实例化（Requirements By Example，RBE），更加明确需求的具体表现。需求越明确，用户、产品经理、开发与测试等之间的理解就越一致（on the same page），更不产生偏差和误解，有利于开发和测试的工作。
基于RBE，开发人员写产品的代码，测试人员可以独立写测试的代码，产品经理的工作也会变得轻松，不需要太多的解释、不需要回答开发和测试的各种问题。

TDD--01--ATDD、UTDD相关推荐

让人傻傻分不清的TDD、ATDD、BDD
前言导入作为一名软件开发从业者,想必你肯定听过以下名词: "TDD" "UTDD" "ATDD" "BDD" &qu ...
软件开发方法论：TDD、BDD、DDD、ATDD、DevOps
软件开发方法论:TDD.BDD.DDD.ATDD.DevOps 一.TDD:测试驱动开发二.BDD:行为驱动开发三.ATDD:验收测试驱动开发四.DDD:领域驱动开发五.持续集成CI 六.持续 ...
损失函数（损失函数、代价函数、目标函数）、MSE、0-1损失函数、绝对误差损失函数、分位数损失函数、Huber损失函数、感知损失函数、Hinge损失函数、指数损失函数、对数损失函数
损失函数(损失函数.代价函数.目标函数).MSE.0-1损失函数.绝对误差损失函数.分位数损失函数.Huber损失函数.感知损失函数.Hinge损失函数.指数损失函数.对数损失函数目录
01背包、完全背包、多重背包问题的C++实现及路径记录
这里主要实现路径记录,只求最值问题移步 01背包.完全背包.多重背包问题的C++实现以下均打印输出路径,即装入背包的物品序号,和最大值. 01背包问题 #include <iostream&g ...
蚂蚁算法的应用（01背包、函数极值、TSP）
蚂蚁算法的应用(01背包.函数极值.TSP) 笔者是一位大一的萌新,这篇算法是自己查阅文献以及参考别人的博客再加上自身的理解写出来的.有错误的地方希望及时指正.这篇文章我使用的是Matlab,后续 ...
自动化测试（二）01-前端测试分为单元测试、集成测试和E2E测试测试工具对比-适合TDD或 BDD、断言、异步测试测试工具的类型
自动化测试(二)01-前端测试分为单元测试.集成测试和E2E测试 & 测试工具对比-适合TDD或 BDD.断言.异步测试 & 测试工具的类型前端自动化测试测试是一个庞大的主题,包括 ...
背包问题详解：01背包、完全背包、多重背包
参考链接: http://www.cnblogs.com/fengty90/p/3768845.html http://blog.csdn.net/mu399/article/details/7722 ...
TDD、BDD、ATDD、DDD 软件开发模式
四个开发模式意思: TDD:测试驱动开发(Test-Driven Development) BDD:行为驱动开发(Behavior Driven Development) ATDD:验收测试驱动开发( ...
【转】浅谈TDD、BDD、ATDD、DDD的区别
四个开发模式意思: TDD:测试驱动开发(Test-Driven Development) BDD:行为驱动开发(Behavior Driven Development) ATDD:验收测试驱动开发( ...

TDD--01--ATDD、UTDD