我们现在程序的开发，很多都是无法测试，对于良好设计的程序，可测试性非常重要，如果一个业务的实现测试成本很高，很难保证它的测试性。
和数据源解耦
要保证程序的可测试性，首先要保证业务从大的数据源方面剥离出来。大的数据源方面包括：Web（页面的输入输出参数），定时执行任务，命令服务器的解析以及数据库，你的业务处理方法/类尽量避免和这些技术/实现的耦合，否则你的测试必须要和这些技术/实现结合，测试成本就会很高，什么是低成本测试？就是写一个测试方法就可以测试。如何来和这些大方面解耦呢？就是将这些大的方面提供的信息作为方法体的参数传进来，就可以实现解耦了。例如电量消息推送中的开关机时间，统计的方式是有逻辑的，如果需要数据库提供相应的数据再来测试，那么这段逻辑的测试成本就高了，这个方法就应该接收两个时间段作为参数，返回一个开关机时间统计。
具有返回值
刚才讲到了对于解耦的重要的方式就是数据源参数化，一个可测试的重要条件就是返回值，输入和输出是否和预期相符是测试的最根本的原则，所以可测试性一定是要求业务逻辑实现是由返回值。
梳理测试细化粒度，确定测试点
下一个就是对于实现细节的梳理，可测试性的还有一个问题就是测试粒度以及测试的业务覆盖。
这里还是以电量推送为例来讲说：
1.计算，包括电量计算，温度平均计算以及开关机时间计算；
2.获取消息，基于计算所获得值，来通过一定的逻辑来决定推送什么消息；
3.发送消息。
对于开关机时间是有逻辑的，输入的是开始时间和结束时间，对于电量计算和温度平均计算因为计算比较简单，即使简单的加减，所以不需要对其进行单元测试；
获取消息，输入的就是两个时间段的电量，平均温度以及开关机时间（6个参数）然后给出推送消息，通过这种方式来验证消息的处理逻辑是否正确；
发送消息，这个测试只能是使用手机来测试。