测试驱动开发学习笔记（UTDD）

What

TDD(Test-Driven Development)是敏捷开发中的一项核心实践和技术、是一种方法论。思路是通过测试来推进整个开发的进行。表现为测试代码优先于业务代码。UTDD呢，其实U就是unit，一般习惯直接叫成TDD。

从长远角度来看，他加快了组织价值流输出的质量、速度、稳定性，所以我想他理应纳入DevOps技能范凑。

Why

为什么要用到他呢？为什么说他加快了组织价值流输出呢？这就要说说他的优点了：

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

以上的优点都在一定程度上提升组织的单位价值输出。

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

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

所以，对于组织来说它的引入则是一把双刃剑，要看用在什么场景以及用到什么程度。成本大于收益那就不要采用了。

How

一、学TDD前该知道的

• 单元测试

  单元测试应该是面向业务的，而不是面向代码的，编写单元测试时应该将一个业务场景当做一个被测试的单元。单元测试应遵循FIRST原则，即快（不依赖外部）、可重复、隔离（独立性）、清晰的成功或失败、频繁且小规模。测试方法命名采用ruby命名法should_xxx_xxx()，内容应用Given-When-Then模式，When时注意运用CQS命令查询分离原则。框架上，主要有做测试的Junit，做验证的AssertJ，做模拟的Mockito。

• 面向对象

  业务代码编写遵守SOLID六大原则，单一职责原则、开闭原则.....等。简单来说要记住迪米特法则，即不要和陌生人说话，以及信息专家模式，以减少外部的数据访问权，然后就是注意组合优先，无差异无继承。

• 重构

  重构即在保证原有代码功能的前提下，去除代码坏味道，进行的一种代码的优化操作。Kent Beck简单设计原则能很好的指导重构：

  1. 通过所有测试
  2. 减少重复代码
  3. 表达程序员的意图
  4. 尽可能减少方法的数量

  重构的运用需要注意重构策略的选择和考虑引入Code Review。另外，重构可以且需要随时进行。

二、TDD

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

TDD还包括以下知识：

1. 需求分析

   TDD遵循简单设计，而这个简单设计不是不设计或少设计，而是清晰的设计。在进行单元测试编写之前，开发人员要用足够的时间去弄清需求，然后再做任务分解和子任务分解。任务分解是对用户故事的拆解，子任务分解是对任务的进一步细分拆解，最终任务和子任务能达到：

   1. 任何子任务均可通过测试来验收
   2. 所有任务的集合恰好等价于原问题域
   3. 子任务之间无交集

   任务之间保持递进原则。

2. TDD的三大支柱

   1. 一次只写一个刚好失败的测试
   2. 不写任何产品代码，除非他刚好能让失败的测试通过
   3. 只在测试全部通过的前提下重构或开始新的功能

3. 编写测试上，涵盖单元测试需要注重的点，比如FIRST原则等。

Last

最后，感谢测试驱动开发训练营张逸老师的倾囊相授！