单元测试er——为何真的真的要写单元测试

优势

为何不少技术或者知识要说优势？由于有些道理看着很简单，你们表面上都以为对，可是作的时候又不去作或者作不到。其中有一个很重要缘由是骨子里或者潜意识并无真实以为这是对的，一旦想去作的时候同时会冒出更多不去作的理由。

方法更健壮

更明确方法的职责

不少小伙伴在编写方法或者程序的时候，先简单写一下“大致”的逻辑。好一些的，在写完后，会根据不一样"状况"验证一下，若是有错再继续修改。可是每每更多的状况下，本身也不知道这个方法对外是一种什么形态，须要知足多少种状况，在异常的状况下提供的是什么表现。因此最终须要使用者（有多是服务调用者，测试者或者真正的用户）来纠正问题，而后再去修订。
这样一来，整个编写方法的周期其实更长，资源的损耗更大。

明确服务职责边界

最好是单一的职责（web层或者流程聚合的接口除外）。

如今是作一个判空的工具。首先要分析的是这个判空的服务范围和职责。一个集合判空、一个字符串判空，跟一个同时支持，包装类，字符串（包括Char等），集合，数组，字典，对象等的判空。这就是两个彻底不一样的职责。不一样的职责最终的case是不一样的。

明确正常case

通常是根据第一步的服务范围和职责来提供的，这样是黑盒，和使用者的视角是同样的（推荐）。也有喜欢经过白盒列case的，经过if等拐点来肯定case（不是很推荐）。最终要保证对的确定是对的，并且要和预期结果同样。

明确异常的case

特别重要的是需求明确的异常，好比说，须要去支付，可是你的钱是非法的。还有抽象域的一些问题要考虑：好比说：冥等，批量操做时的原子性，依赖服务异常等。最终要保证错的必定要错

明确case输入

明确每个case输入应该是什么，只关注和这个case相关的，这样每一个都是具义的。若是一个case有太多的输入和case无关，最好是考虑对依赖的结点进行mock。

明确case输出

明确每个case输出是什么。这样能够进行断点和结果预期。而后执行时，就能反向知道这个方法提供的服务是否正确。若是不正确的话，须要修改方法。

大胆重构

只有有case了，才能使用自动化的验证。不然有可能只是改了一个很小的地方，可是会引发其余case的错误，改一个小地点就得手动的把全部case测试一下。并且最惧怕的是历史方法，由于没有人能说清楚到底有多少种case。

重构时错误常见的场景：

• 一个判断条件或者设计的链路，想的是对的，可是写的时候出错，致使正常业务都出错了
• 误删或者重构时遗漏代码，致使部分业务错误。

让编写的方法更独立

一旦耦合度过高，在造输入数据的时候就会特别困难。这样也反向的能促进咱们在写代码的时候尽量的不依赖，至少不深度或者嵌套依赖。

好比：之前是写个a方法，要知道b方法使用c对象的d属性。这样造输入的时候就特别难受。因此就会促进咱们变成写个a方法，最多使用和关心b方法。其余是b方法的职责，让b方法本身去测试。

这样也能让每一个方法更原子和内聚。

隔离依赖

无感依赖细则

不用关注依赖的细则，特别是不用跨层或者跨服务去关注细节。从树状结构关注点变为平级关注点。从关注细则到关注服务。

并行开发

之前的方式是，相互耦合依赖，上游没作完，下游没数据，没办法或者很难并行开发。可是使用隔离后，就能够基于接口的服务职责来mock预期的行为，因此互相就不会依赖，能够并行去开发。

结果可预见

比较头疼的是，要根据不一样的业务case,造各类场景，有的场景还要开关或者编数据等特殊方式才能够。可是使用隔离mock后，想要有什么预期结果是很是稳定的，也是很简单天然的。
好比：有N个集合中，调用指定的服务后，若是有部分失败，部分红功。这个case用mock是很是好造的。

解决重复问题

当前，在编写单元测试的时候也会有不少工做量，因此能够经过单元测试框架来解决重复的问题。

• mock简洁化和自动化。经过注解和ioc基本很容易作到。
• 设置参数很头疼，还有不少魔鬼数字，有的时候还得硬着头皮造一些无喱头的数据。

写什么

单元测试不是越多越好，而是越有效越好！进一步解读就是哪些代码须要有单元测试覆盖：(引用Kent Beck)

• 逻辑复杂的
• 容易出错的
• 不易理解的，即便是本身过段时间也会遗忘的，看不懂本身的代码，单元测试代码有助于理解代码的功能和需求
• 公共代码。好比自定义的全部http请求都会通过的拦截器；工具类等。
• 核心业务代码。一个产品里最核心最有业务价值的代码应该要有较高的单元测试覆盖率。

怎么写

• 根据case准备数据,mock
• 触发验证场景
• 期待的结果是什么

什么时候写

写单元测试的时机不外乎三种状况：

• 在具体实现代码以前，这是测试驱动开发（TDD）所提倡的；
• 与具体实现代码同步进行。先写少许功能代码，紧接着写单元测试（重复这两个过程，直到完成功能代码开发）。其实这种方案跟第一种已经很接近，基本上功能代码开发完，单元测试也差很少完成了。
• 编写完功能代码再写单元测试。个人实践经验告诉我，过后编写的单元测试“粒度”都比较粗。对一样的功能代码，采起前两种方案的结果多是用10个“小”的单测来覆盖，每一个单测比较简单易懂，可读性可维护性都比较好（重构时单测的改动不大）；而第三种方案写的单测，每每是用1个“大”的单测来覆盖，这个单测逻辑就比较复杂，由于它要测的东西不少，可读性可维护性就比较差

我我的推荐的是，先大致明确方法的职责和边界，而后把突出的case大致设计出来。而后和具体实现代码同步。一来能够补充case，只有对需求有必定的理解后才能知道什么是代码的正确性，才能写出有效的单元测试来验证正确性，而能写出一些功能代码则说明对需求有必定理解了。二来可使用重构的思惟去解决思考两次并且还互相打架的问题。

陷阱

多验证点

多验证点的case，一旦业务稍微改变一点点，很容易造能case的经过不了，也说明了方法的职责不是很原子。有可能能够进一步拆分。

过分依赖上下文

说明方法不够健壮，职责不清楚。若是一旦上下文变动，就会致使case的失败。介时就分不清楚是上下文数据的问题，仍是本身服务的问题。

还须要作的事

工具类库

虽然，单元测试框架作了不少重复的事，可是还有不少重复的事，其实都是能够封装成工具类的。
好比：一个方法有不少参数，而后每一个参数都均可以赋默认值，那就得手写半天。像这种抽象上一致的均可以封装成工具类

规范

在不一样的单元测试之间，其实有不少重复的思考和沟通。
好比：单元测试的方法名怎么命名更好些？一个方法放一个case仍是多个case。什么样的异常须要验证case。

有了规范或者规约后。重复的内容能够经过代码片断，文件模板等方式半自动化的生成，甚至能够经过代码生成器等小工具，默认把一些手工的操做怎么自动生成。并且规范后，你们阅读和维护单元测试的成本就会下降。

理想状态的单元测试，应该是只验证正确的业务点，和异常的业务点，以及一些从系统和抽象问题领域角度的异常业务点。其余的要么交给工具，要么交给规范。

参考资料

• 为何要写单元测试，什么时候写，写多细
• mockito官方文档