最近一段时间结束了一个Sprint，在这次的开发当中有些东西觉得还不错有总结分享的价值，所以整理成本文；
重构已是老生常谈的话题，我们或多或少对它有所了解但是对它的深刻理解恐怕需要一段实践过后才能体会到；提到重构就不得不提为它保驾护航的大功臣单元测试，重构能有今天的风光影响力完全少不了单元测试的功劳；最近一段时间写单元测试用例的时间远超过我写逻辑代码的时间和多的多的代码量，这是为什么？我一开始很难给自己一个理由去做好这件事，心态上还是转变不过来，可是每当我心浮气躁的时候它总能给我点惊喜，让我继续下去，天生具有好奇心的程序员怎么会就此结束呢，只有到达了一扇门之后我们回过头来看一下走的路才能真正的明白这是条对的路还是错的路；
单元测试简单写起来没有什么太大问题，但是我们不仅为了达到代码的100%覆盖还要到达到逻辑的100%覆盖，代码的覆盖不代表逻辑的覆盖；一个简单的逻辑判断虽然只有一行代码，但是里面可能会有正反向很多种逻辑在里面；比如：Order.ToString()简单的代码，想要覆盖很简单，只要对象不为空都能正确的覆盖到，但是如果我们没有测试到它为NULL的情况下的边界逻辑，这个时候我们就会漏掉这种可能会导致BUG的逻辑路径；所以我们会尽可能的多去写用例来达到最终的理想效果；
（总之把单元测试的所有精力集中在可能会出问题的地方，也是自己最担心的地方，这个地方通常是逻辑比较复杂的地方；）
2】单元测试、测试用例代码重复问题（大量使用重复的Mock对象及测试数据）
单元测试代码中最常见的代码就是Mock或者Fake接口逻辑，那么在一个具有上百个用例覆盖的代码中会同时使用到一组相关的Mock接口对象，这无形中增加了我们编写单元测试的效率给后期的维护测试用例带来了很大的隐患及工作量；
单元测试代码的组成都是按照用例来划分，一个用例可以用来包括一个单一入口的所有逻辑也可以是一个判断分支的部分逻辑；为了构造一个能完美覆盖的代码步骤，我们需要构建测试数据、Mock接口，划分执行顺序等等，那么一旦被测试代码发生一点点的变化都会很大程度上影响测试代码，毕竟测试代码都是步步依赖的；
那么我们应该最大程度的限制由于被测试代码的变动而引起的测试代码的变动，这个时候我们应该将重构应用到测试代码中；
2.1】单元测试的继承体系（利用超类来减少Mock对象的使用）
将多个相关的测试用例代码通过超类的方式关联起来统一管理将大大减少重复代码的构建；就跟我们重构普通代码一样，将多个类之间共享的逻辑代码或者对象提取出来放到基类中；这当然也同样适用于测试代码，只不过需要控制一些更测试相关的逻辑；
其实大部分重复的代码就是Mock接口的过程，我们需要将它的Mock过程精简化，但是又不能太过于精简，一切精简的过程都是需要牺牲可观察性；我们需要适当的平衡提取出来的对象个数，将它们放入基类中，然后在Mock的时候能通过一个简单的方法就能获取到一个Mock过后的对象；
下面我们来看一下提取公共部分到基类的一个 简单过程，当然对于大项目而言不一定具有说服力，就当抛砖引玉吧；
2.1.1】公用的Mock对象
首要的任务就是将公共的Mock接口提取出来，因为这一类接口是肯定会在各个用例中共享的，提取过程过主要分为两个重构过程；
第一：将用例中的公用接口放到类的声明中，供所有用例使用；
第二：如果需要将公用接口提供给其他的单元测试使用，就需要提取出相关的测试基类；
我们先来看一下第一个过程，看一下测试示例代码：
| namespace UnitTestRefactoring { public class OrderService { private IServiceConnection ServiceConnection; private IServiceReader ServiceReader; private IServiceWriter ServiceWrite; public OrderService(IServiceConnection connection, IServiceReader reader, IServiceWriter writer) { this.ServiceConnection = connection; this.ServiceReader = reader; this.ServiceWrite = writer; } public bool GetOrders(string orderId) { if (string.IsNullOrWhiteSpace(orderId)) return false; return true; } } } <STRONG> </STRONG> |
