单元测试-FizzBuzz练习

单元测试

公司最近推行单元测试，故对此作出学习总结，方便自己以后查看；

• TDD Test Driven Development（测试驱动开发）
  参考：https://www.jianshu.com/p/62f16cd4fef3

TDD是指：	在编写业务代码之前先编写单元测试代码，换句话说就是给出来的需求，以单元测试的形式先实现；
或者说 以保证单元测试通过为目的，去写代码；

自己的误区

在公司架构师没有推行单元测试之前，一直认为单元测试很耽误时间，特别是在自认为是敏捷开发的团队中，
可能已经没有充足的时间开发，还需要再写单元测试，觉得没有必要；

但是经过架构师的熏陶，初步对单元测试有了好感；
1.编写合格的单元测试其实已经把主干的业务逻辑实现了；
2.当需要重构代码时，有单元测试保证重构后不会引入另外问题，非常有安全感；
3.假设出现bug，能够迅速找到可执行的程序上下文，并且能够迅速准备测试数据；
4.如果把写代码比做是造房子，那么单元测试可能就是验收报告了，交付出去的东西都是有质量保证的；

TDD-FizzBuzz训练

参考：https://zhuanlan.zhihu.com/p/150421025

完成上面训练后，基本对测试驱动开发的有了初步了解；
初步需求：当只需要对3的倍数报Fizz对5的倍数报Buzz时，非常简单实现

当需求不断增加，为了保证测试通过，需要不断往sayNumberOff（）方法增加逻辑；

当我们实现完业务逻辑后发现代码其实有很多坏味道，因为有单元测试保障，我们可以放心大胆的改造方法；
演进式设计

个人对TDD初步的理解就是：以通过单元测试并达到要求覆盖率为前提，去实现业务逻辑，测试驱动开发，并未后期的重构提供保障；

结合实战

单元测试结构：
Given ---》 When ---》Then

Given 准备测试上下文阶段：主要负责创建测试数据，构造mock方法返回值；
为什么要构造mock方法返回值呢：因为在这里只关心主业务逻辑，
其他次要的引用都需要mock掉，本质是“控制变量法”，将原本依赖的N个变量，变成N个常量；

When ：主业务执行

Then：验证阶段，并且考虑各种异常处理情况；