菡萏如佳人测试驱动编程-进阶单元测试
单元测试
要打造出出类拔萃的作品，你必须专注于最小的细节
单元测试正确打开方式
- 单元测试应该是测试流程中占比最重的部分
- 单元测试通常来说是指方法，但是有些情况下，整个类乃至整个应用程序都可视为单元
- 单元测试是为了缩小其它（功能，集成）测试的范围，如果一个组织主要依赖于手动测试，这本身就是有问题的
- 单元测试编写更容易，也能让代码的问题尽早暴露
- 单元测试为代码重构提供了有力的支持
各类测试比较
下图测试金字塔展示的是UI测试、集成测试、单元测试之间的比重，单元测试要比其它测试多得多
拿最常见的用户注册测试场景举例，最常看到的测试用例就是要考虑用户名为空、密码为空、用户名格式、密码格式、用户名是否存在、密码安全等级等等。
仅为测试这一项功能，就可能需要数十个测试，再加上边界值等情况可能导致上百个测试用例，如果是人工的UI测试，那么代价将是非常大的。
如果使用单元测试来做这些会简单和方便的多，人工只需要填写一个集成测试，检查是否调用了正确的后端方法即可，而无需关注细节。当注册逻辑发生改变了也没关系，因为新单元测试会自动进行测试。
TDD中的单元测试
TDD中的单元测试和传统的单元测试有什么不同呢？答案是：时机
看过我之前写的一篇文章，测试驱动编程快速入门的应该都知道了一个名字：红绿重构
传统先写业务再写单元测试，主要是为了验证业务代码写的对不对，而TDD中的单元测试主要目标是作为驱动开发和设计的动力，定义了我们应该做什么以及做到什么程度，验证只是副产品。
完成的工作量和具体的测试(单元、功能、集成)有关，TDD中的单元测试制订接下来完成尽可能小的任务，要求我们遵循一些设计原则(KISS、SOLID)，确保代码的可测试性和解耦性。
TDD迫使我们详细地考虑需求和设计，编写整洁而可行的代码，以及创建可执行的需求并频繁重构。
示例实战
接收同事的需求
你的同事正在开发一个远程控制轮船的程序，他已经完成了一部分工作，但是他休假去了， 现在任务交给了你。你的同事是一个TDD的践行者，你接下来要在他完成的工作基础上继续开发
下图是你同事设计的几个主要的类：
- Ship：表示轮船，目前没有任何方法，继续要迭代的地方
- Point：表示二维坐标
- Direction：代表方向的枚举类以及左右转弯的方法
- Planet：地球，轮船航行的地方，包含最大的航行坐标点以及分布了哪些障碍物设置
- Location：轮船当前方位，包含所在的坐标以及当前的行驶方向，可以前进后退、进行航行
下面是你同事已经完成的测试验证方法，所以请你放心的改造下去
方向测试类
轮船行驶范围(地球)测试类
二维坐标测试类
方位（包含方向与二维坐标）测试类
控制方向和坐标参考系如下：
特别要注意的是地球是圆的，起点和终点是重叠的。例如：往x轴最远处前进将回到x=1的坐标点
开始迭代需求
上面看到同事之前写的代码所有测试经过都是绿灯，我们可以放心的进行后面的需求迭代了
故事迭代1
我们需要给定轮船的起始位置以及方向
因为每次控制轮船的提前肯定是要有一艘轮船，所以在每个测试方法前都应该需要一艘船，我们把它放在@BeforeEach注解的方法里
Ship默认只有无参的构造函数所以报错了，这也是正常的红-绿-重构的红阶段，接下来我们进入绿阶段
写一个测试方法测试下
故事迭代2
轮船可以前进或后退
在编写轮船可以前进后退的时候，我们是不是要编写各个方向的前进和后退测试方法呢？类似下面的
该测试方法测试的是轮船往北移动，Y轴的坐标将加1
实际上我们不应该这么去编写测试，原因有三：1，我们的测试方法的结果依赖了其它方法、类的内部工作原理(否则我们怎么知道y轴需要检测的是8)；2，会导致编写多个测试方法，我们肯定要把东南西北各个方向相关的方法都写一遍；3，依赖的其它方法虽然经过测试，但是如果发生变化，我们需要找到调用这个方法的所有地方进行修改
这里我们可以巧妙利用已经存在的方位方法进行测试用例编写：
编写moveForward()方法，使其变绿
轮船前进的完成了，后退的功能非常相似，就不详细说明了
故事迭代3
轮船可以左转或右转
和故事迭代2有点类似，在之前辅助类Location中包含了左右转的方法，我们可以结合实现
故事迭代4
轮船接收一个指令然后完成相应的动作（比如：lrfb表示左转右转前进再后退）
每个命令都用一个字符表示：f表示前进、b表示后退、l表示左转、r表示右转
先编写一个测试用例，接收一个字符串，解析并调用相关的方法
完成 红的步骤后进入 绿
测试下结果没问题
故事迭代5
轮船行驶的地球是圆的，所以可以从一边的尽头跨越到另外一边
目前为止，轮船的构造函数只有一个参数location，代表轮船的方位，现在需要引入一个planet参数代表行驶的范围（水域大小）
新增一个两个参数的Ship构造函数，使其变绿
我们发现其实之前有过ship单个参数的测试方法，而且还有一个初始化方位的方法，其实我们可以将其重构成每次测试前都初始化一艘带方位和行驶范围的轮船
刚才的测试方法就可以简化为
Ship的构造参数也只需要保留一个就可以了
接下来编写一个往东边再前进回到x轴坐标1的测试方法，因为我们初始化的时候船就是朝东的，所以不同重新设置方向了
跑下测试用例肯定报错的，我们期望的是1，但是实际是51，超出边界了
度假中的同事之前已经在location辅助类中完成了跨越边界的逻辑，所以我们只要重构下ship中的前后形式方法，带上边界范围即可
运行下ship的所有测试方法，全部绿灯，故事迭代完成
故事迭代6
每次移动需要进行障碍检测，遇到障碍的话停在原处报告遇到的障碍
地球上的水域不是畅通无阻的，有暗礁和陆地，所以我们得在行驶区域中加入障碍物，轮船行驶的时候先检查是否有有障碍物
我们首先在初始化的时候在行驶区域内加入障碍物
重构下初始化的方法
无需添加实现，测试就可以通过
接下来我们测试有障碍物的时候，轮船无法行驶，我们的设计是让接收指令的方法返回一个字符串，代表每条指令的执行情况
根据测试代码，障碍物和船形式的路线如下：(先往蓝色箭头指示方向，后往绿色箭头指示方向)
执行下肯定是报错的，因为我们之前逻辑不支持障碍物，接下来要重构下我们的业务代码：
第一个地方：调用位置帮助类的时候，前进后退的方法要加上障碍物信息
第二个地方：指令接收方法要判断每次执行的结果，拼接成字符串返回
运行下我们的测试类
至此我们的遥控轮船开发完成，同事度假回来了，后面的需求交给他吧，毕竟我们也成为了TDD的践行者，让他放心的迭代吧
PS：验收代码仓库 https://gitee.com/hzqiuxm/tdd-demo-lessons.git 的ship模块