【How To】如何写出易于测试的代码？

无关的前言，一点小心得

最近一直在疯狂敲码，感觉自己对代码设计和抽象越来越得心应手了，开始享受代码抽象的这个过程，每个模块就像精心设计的一个个小玩具，精巧优雅，看着让人舒服，这时候开始体会到设计模式中的思想，为什么要遵循：开闭原则，为什么要面向对象，代码也可以写的很美

正题

我最近又在思考测试对项目的意义和实践，毫无疑问测试是开发中可以说是最最最重要的东西了，但是往往测试时常给我们的感觉就是困难、不想写、不想做，我总结了这几点：

• 测试的成本是巨大的，包括时间成本、资源成本
• 测试的外部环境依赖很多，或者有时根本无法获取到
• 代码的结构设计不够好，测试困难

这些问题都是我们再开发过程中经常会遇到的问题，所以我觉得开发时候有一个思想要遵循，这也是我这篇文章的一个核心思想：

• 通过将资源和业务逻辑代码拆分，从而实现外部依赖和内部业务逻辑的解耦，进而降低测试的难度

什么叫做资源和逻辑拆分呢？比如你测试一个登陆逻辑，你要获取的资源有：zookeeper，redis，mysql 等等一系列的外部资源，有了这些你终于开始了你的测试，但是此时你只是想测试一下你的用户登录的验证逻辑，你却调用了一大堆看似必要，实际无关的资源，其实这就是间接给自己的测试添加了难度了。
其实这里完全可以将验证逻辑抽取成一个小的部件，这个部件对外部什么都可以不依赖，只是做业务条件判断，通过了测试，这个”小零件“就可以说没问题了。接下来要做的就是把一个大的业务拆成一个个小的”零件“，而程序代码作为一个理想化的组件，只要你的每一个零件都没有问题，那么整个模块组合起来就不会有问题，这个时候开发效率会大大提高，而且bug率同样也会降低。
那么这个时候就有小朋友问了，这个”资源“我在什么时候加载呢？那就是我推荐就是在合适的地方加载了，越能抽象到上层，越能够做到资源和逻辑的解耦，代码的可测试性就越好。
而且如果要涉及到这种需要外部资源依赖的测试，那么这就属于集成测试的范畴了，属于更高层级的测试。所以某种程度上我们是通过降低维度来简化测试，降低测试的难度，提升测试的效率。