[最主要的模式]【Java设计模式规范与重构】二重构的保障：单元测试，以及如何提高代码可测试性

只不过之前的工作中强调过很多次他们做试验的重要性，例如讲程序标识符的：【C程式设计最差课堂教学 一】程序标识符课堂教学，讲程序标识符规范化的【腾讯Java程式设计规范化学习 四】Java产品质量安全法律条文，讲USB试验的：【C程式设计最差课堂教学 十三】USB试验课堂教学，这里阿尔宗就不再详细展开了，回顾下程序标识符的基本原理，重点来看怎样提升标识符的可试验性。

依次从WHAT，WHY，HOW，HOW去了解。

程序标识符由RD他们来撰写，用以试验他们写的标识符的精确性。它与软件系统试验的区别是试验发射率

软件系统试验的试验第一类是整个系统或是某个机能模块，比如说试验帐号、登入机能与否正常，是一种起新端（end to end）的试验。程序标识符的试验第一类是类或是表达式，用以试验两个类和表达式与否都按照预期的方法论继续执行。这是标识符层次的试验

程序标识符相对于软件系统试验（Integration Testing）来说，试验的发射率更小许多。

程序标识符除了能有效地为解构添砖加瓦之外，也是保证标识符产品质量最有效的两个手段之一（另两个是 Code Review），写程序标识符有如下好处：

写程序标识符能有效地辨认出标识符中的 bug，通过写程序标识符可以节约很多 fix 合情理 bug 的天数，能够有天数去做其他枭女的事情。写程序标识符能辨认出标识符结构设计上的难题，标识符的可试验性是评判标准标识符产品质量的两个重要标准。对于一段标识符，如果极难为其撰写程序标识符，或是程序标识符写起来很狼狈，须要依靠程序标识符框架里很高级的特性才能完成，那常常就意味着标识符结构设计得不够合理，比如说，没有采用依赖注入、大量采用动态表达式、函数调用、标识符高度谐振等程序标识符是对软件系统试验的有力补充，程序代码的 bug 常常出现在许多拉普拉斯、异常现象下，比如说，余数未判空、网络延时。而大部分异常现象都比较难在试验环境中模拟写程序标识符的操作过程本身是标识符解构的操作过程，稳步解构应该作为合作开发的一部分来继续执行，写程序标识符实际上是破冰继续执行稳步解构的两个重要途径。结构设计和同时实现标识符的时候，他们极难把所有的难题都想清楚撰写程序标识符就相当于对标识符的一场自我 Code Review，在这个操作过程中，可以辨认出许多结构设计上的难题（比如说标识符结构设计的不可试验）和标识符撰写方面的难题（比如说许多拉普拉斯处置不当）等，然后针对性的进行解构写作程序标识符能帮助他们快速熟悉标识符，文件格式紧密结合程序标识符，他们不须要深入细致的写作标识符，便能晓得标识符同时实现了什么机能，有什么样特定情形须要考量，有什么样拉普拉斯须要处置。不须要深入细致的写作标识符，便能晓得标识符同时实现了什么机能，有什么样特定情形须要考量，有什么样拉普拉斯须要处置。程序标识符是 TDD 可破冰继续执行的改进方案，试验驱动力合作开发（Test-Driven Development，简称 TDD）是两个经常被提及但很少被继续执行的合作开发商业模式。它的核心指导方针是试验用例圣吉龙县标识符撰写，但极难破冰，不如先写标识符，紧接着写程序标识符，最后根据程序标识符意见反馈出来难题，再回过头去解构标识符，隐性落实TDD，试验驱动力解构与FIX

只不过程序标识符是对标识符结构设计和机能方法论的一场深思，粗发射率的CR，紧密结合CR，推动和保证稳步解构。

物理上可以借助Java 中比较出名的程序标识符框架有 Junit、TestNG、Spring Test 等。这些框架提供了通用的继续执行流程（比如说继续执行试验用例的 TestCaseRunner）和工具类库（比如说各种 Assert 判断表达式），而主观经验上要有这样的意识

撰写程序标识符尽管繁琐，但并不是太耗时，不同试验用例之间的标识符差别可能并不是很大，简单 copy-paste 改改就行可以稍微放低对程序标识符标识符产品质量的要求，命名稍微有些不规范化，标识符稍微有些重复，也都是没有难题的，但标识符规范化意识要时刻有，要达到想降低要求都降不了的水平覆盖率作为衡量程序标识符产品质量的重要但不是唯一标准，更重要的是要看试验用例与否覆盖了所有可能的情形程序标识符不要依赖被试验表达式的具体同时实现方法论，它只关心被测表达式同时实现了什么机能。切不可为了追求覆盖率，逐行写作标识符通操作过程序标识符框架无法试验，多半是因为标识符的可试验性不好，须要思考下标识符的结构设计

程序标识符是两个透明试验，他们只关注机能而无需关注同时实现细节，关注的机能要关注与否覆盖了所有可能场景

一方面，写程序标识符本身比较繁琐，技术挑战不大，很多程序员不愿意去写；另一方面，研发比较偏向快、糙、猛，容易因为合作开发进度紧，导致程序标识符的继续执行虎头蛇尾。最后，关键难题还是团队没有建立对程序标识符正确的认识，觉得可有可无，单靠督促极难继续执行得很好

简而言之，标识符的可试验性，是针对标识符撰写程序标识符的难易程度。对于一段标识符，如果极难为其撰写程序标识符，或是程序标识符写起来很费劲，须要依靠程序标识符框架中很高级的特性，那常常就意味着标识符结构设计得不够合理，标识符的可试验性不好.

怎样让标识符可试验性更好呢？最常用的方式是依赖注入了，通过DI同时实现反转，将第一类的创建交给业务调用方，这样就可以随意控制输出的结果，从而达到mock数据的目的，最好搭配多态，让mock类之间基于父类注入，例如将Mock数据注入到类中进行试验。例如

通过依赖注入注入到主类

采用时直接注入Mock类

对于许多须要外部依赖的远程服务，因为他们不能修改远程服务标识符，所以须要组合mock、二次封装、依赖注入等方式解决，也是类不直接依赖于远程类，而是依赖于封装在远程类之上的本地方法，试验的时候mock封装类即可。例如在远程调用的RedisDistributedLock之上封装一层而不是直接调用

主类与依赖的封装类通过依赖注入来组织

他们在试验时就可以直接将Mock的封装类注入主类试验

下面整理许多影响标识符可试验性的难题

所谓的未决行为方法论是，标识符的输出是随机或是说不确定的，比如说，跟天数、随机数有关的标识符，例如：

这是一段计算延期天数的标识符，当前天数一直在变，而这种变化不是通过参数传递进来的，所以随着天数的推移，程序标识符的输出结果会有不同，所以为了提高标识符可试验性，可以把currentTimestamp 这个参数当成局部变量传进来：

函数调用是一种面向操作过程的程式设计风格，有种种弊端。滥用函数调用也让撰写程序标识符变得困难，同两个函数调用被多个程序标识符用例访问并设置值，会让程序标识符结果不准确，例如

position 是两个动态函数调用，第两个试验用例继续执行完成之后，position 的值变成了 -1；再继续执行第二个试验用例的时候，position 变成了 5，move() 表达式返回 true，assertFalse 语句判定失败。所以，第二个试验用例运行失败

动态方法跟函数调用一样，也是一种面向操作过程的程式设计思维。在标识符中调用动态方法，有时候会导致标识符不易试验。主要原因是动态方法也极难 mock，因为动态方法没有多态的特性，没办法采用mock方法。

相比组合关系，继承关系的标识符结构更加谐振、不灵活，更加不易扩展、不易维护。实际上，继承关系也更加难试验。这也印证了标识符的可试验性跟标识符产品质量的相关性。

如果父类须要 mock 某个依赖第一类才能进行程序标识符，那所有的子类、子类的子类……在撰写程序标识符的时候，都要 mock 这个依赖第一类。对于层次很深（在继承关系类图中表现为纵向深度）、结构复杂（在继承关系类图中表现为横向广度）的继承关系，越底层的子类要 mock 的第一类可能就会越多，这样就会导致，底层子类在写程序标识符的时候，要两个两个 mock 很多依赖第一类，而且还须要查看父类标识符，去了解该怎样 mock 这些依赖第一类。

利用组合而非继承来组织类之间的关系，类之间的结构层次比较扁平，在撰写程序标识符的时候，只须要 mock 类所组合依赖的第一类即可。

如果两个类职责很重，须要依赖十几个外部第一类才能完成工作，标识符高度谐振，那在撰写程序标识符的时候，可能须要 mock 这十几个依赖的第一类。不管是从标识符结构设计的角度来说，还是从撰写程序标识符的角度来说，这都是不合理的

程序标识符好像写的没有之前多了，更多的是写相对更粗发射率的USB试验，两个主要原因是觉得写程序标识符琐碎，写USB试验能通就证明主流程OK，就能提测了，事实上在比较紧凑的迭代节奏里这是常态，幸而试验同学的软件系统试验比较给力，没出什么难题，但只不过也不能老依赖于USB试验和软件系统试验，程序标识符也有必要写的，更多的是通过写单测CR下他们的标识符吧，践行稳步解构的理念。对于标识符的可试验性而言，只不过他们日常基于Spring去合作开发，本身大多数场景都是依赖注入，所以体会可能没有那么深，至于对于远程服务的依赖，采用二次封装是个不错的方法，但是标识符侵入性还是有许多的，只不过也能通过许多试验工具例如AnyMock解决。重要的还是要有单测和提高标识符可试验性的意识吧…