在公司项目开始的阶段由于准备不完善和个人能力不足，忽略了编写正规的单元测试的好处，所以在长达一年的时间里，项目在上线前的构建过程中其实是没有跑过测试的，在项目上线的最初几个月里，由于项目功能涉及的方面较少，所以可以轻松的确保上线代码不存在严重的问题。

随着项目涉及的方面逐渐扩大，没有正规的测试架构的问题逐渐显现出来，我还记得一次由于spring循环注入导致接口的事务失效的问题，足足浪费了我两天的时间查找错误，如果在上线前经过了严格单元测试，也不会出现如此低级的错误。

现在项目的生产代码已经到了人工无法掌控的地步，在线上频繁出现的小bug严重影响了生产代码的可靠性和我的生产效率。这都是当时项目开发阶段不重视单元测试给自己埋的坑。

我现在也渐渐发现了一个道理：越是项目架构早期的缺陷，发现的越迟，危害越大。 在接下来的时间里我决定消除这个隐患---通过重写结构良好，可靠度高的单元测试。

下面的编写注意事项来自科斯凯拉的《Effective Unit Testing》 在重写单元测试的过程学习到的经验与感悟会慢慢的补充

##衡量测试代码的指标

• 测试代码的可读性
• 测试的可靠度
• 测试的执行速度

##测试反例

###坏味道

• ####可读性
  1. 断言的表达方式要明确表达验证意图，避免认知负担
  2. 断言的范围要紧密贴合测试目的。不能高于本测试目的，永远成功的断言没有价值。也不能将断言范围覆盖多个测试意图，永远失败的测试缺乏可维护性。断言范围不明确造成理解困难。
  3. 避免测试方法中的过度细节，测试方法应该能快速表达测试内容。注意方法名，分离多余的安装方法，重用共用的测试代码
  4. 避免多重职责，单个测试的测试内容应该只关注目标代码的一个行为，便于快速定位测试问题
  5. 避免将不必要的测试逻辑与数据文件分割，简单的数据应该内联到测试之中，如果不能做到，那么数据文件也应该和测试方法待在一起
  6. 避免测试代码中意义重要但是表达不明的膜法数字，使用有意义的静态变量或者方法名来代替
  7. 避免冗长的安装，抽取细节，整合到命名浅显的方法名中
  8. 避免不必要的断言保护，增加冗余的断言

• ####可维护性

  阅读代码比编写代码频繁的多

  1. 避免重复 结构重复和语义重复
  2. 避免测试方法中的条件逻辑，他会造成的断言被回避不执行
  3. 避免间歇性成功的测试，同一个测试数据一个测试方法的返回结果应该始终一致
  4. 避免残缺的文件路径，应该使用类路径、项目路径等相对路径
  5. 测试生成的共享文件等资源在测试结束之后就应该删除，避免测试之间相互影响
  6. thiread#sleep 使用countDownLatch来代替
  7. 避免参数化测试模式滥用
  8. 提高测试类的内聚，合理使用公共基类

• ####可信赖性
  1. 测试项目中不应该存在被注释掉不运行的代码
  2. 代码注释要和测试代码同步 好的代码注释为什么而非做什么
  3. 测试失败时就应当失败
  4. 避免轻率承诺避免空的测试方法，没有任何检查的测试没有用处，测试内容不全，测试的代码比声明的少
  5. 避免降低期望，源于断言过于模糊或者不能描述期望行为，避免虚假安全感
  6. 避免基于所运行的平台而决定断言结果
  7. 用断言替换条件
  8. 分支条件的不同路径应该分解到单独的测试中，所有的测试都应该有失败的机会

###设计原则 模块化编程有理由提高代码可测性

模块化设计原则

####SOLID

1. s---单一职责原则 类小而专注，具有高内聚。发生变化的原因只有一个
2. o---开闭原则 对扩展开放，对修改关闭 --可在不修改代码的情况下扩展功能
3. l---里是替换原则 子类是父类的扩展，子类能替换父类进行工作
4. i---接口隔离原则 接口小而专注，提高可测试性
5. d---依赖翻转原则，类不用自己实例化协作者，而是选择依赖接口

####可测性的设计指南

避免使用private修饰符 避免使用final修饰符 避免工具类之外的static方法 避免被测方法中使用new的硬编码 避免在构造函数中包含逻辑 避免使用单例 使用继承达到重用会抑制可测性