如何写好单元测试
代码的单元测试非常重要，是团队开发中必不可少的一环！这个懂的人，应该无需赘言了吧！！！（重要的事情说三遍）
那如何才能写好单元测试呢？网上提到过很多优秀的项目单元测试必须满足的原则，诸如覆盖率，完整性，自动化等等。今天我想从为什么写不好单元测试，甚至是无法写出单元测试的理由入手，给出一些个人的建议与方法，希望能给大家一些启发和思考。
为什么写不好单元测试呢？很多人给出的理由是，系统的耦合性太高了，为了测试一个接口，需要考虑太多东西了。以我们项目的实际为例，业务层的接口实现调用了事务控制层的接口，然后事务控制层的接口实现又调用了DAO层的接口，一层扣一层，真是不好写啊！！
要写好这类代码的单元测试，普世的原则自然是解耦了。想必道理大家都懂，但是真正做起来就很麻烦了。其实，我的总结是，各层既然有明确的分工和职责，那单元测试关注的点应该也是自身的职责所在。还是以我们的项目为例，业务层的职责是面向过程的代码过程，每个接口实现的是业务流转和逻辑，业务层并不关心数据怎么存储和读取（这不应该是业务层应该关心的）。业务层的单元测试也应该服务于此，比如一个保存的接口，我们只需要测试其要保存的对象数据是否完整，校验规则是否能照顾到。有人可能问，如果这个接口有返回值，当然好验证了，那没有返回值的情况怎么验证呢？这个时候我们就需要用到mock的思想了。
话不多说，上点代码吧。
要测试业务层这个接口如下：
public RemoteResult<Boolean> savePushContent(final PushContentApi pushContentApi) {
return RemoteServiceInvoker.doRunWithExHandler(new RemoteObject<Boolean>() {
@Override
public RemoteResult<Boolean> run() {
RemoteResult<Boolean> result = new RemoteResult<Boolean>(true);
pushContentApi.validateAddBean();
if (TYPE_FASTPUSH.equals(pushContentApi.getType())) {
pushContentApi.setSerialNo(SERIALNOFAST_PRE + IdGenerator.genSerialNoWithDateAndRandom2());
} else {
pushContentApi.setSerialNo(SERIALNO_PRE + IdGenerator.genSerialNoWithDateAndRandom2());
}
pushContentApi.setSendState(SEND_STATE_WAIT_CONFIRM);
setSendInfo(pushContentApi);
pushContentManager.savePushContent(BeanCopyUtil.createAndCopy(pushContentApi, PushContent.class));
result.setT(true);
return result;
}
});
}
代码里调用了pushContentManager的接口。我们mock一下这个manager，然后实现一下savePushContent一下。
@Override
public void savePushContent(PushContent pushContent) {
assertNotNull(pushContent);
assertNotNull(pushContent.getSerialNo());
assertEquals("测试内容", pushContent.getContent());
assertEquals(Long.valueOf(-1), pushContent.getCreatorId());
assertEquals(PushContentConstants.SEND_STATE_WAIT_CONFIRM, pushContent.getSendState());
if (pushContent.getTaskId() == null) {
assertEquals("13810001000,13810001001", pushContent.getTestMobiles());
assertEquals(Long.valueOf(2), pushContent.getSendNum());
} else if (MockDataTaskManager.DATA_TASK_ID.equals(pushContent.getTaskId())) {
assertEquals(Long.valueOf(201), pushContent.getActivityId());
assertEquals(Long.valueOf(100), pushContent.getSendNum());
}
}
然后单元测试如下：
@Test
public void testSavePushContent() throws Exception {
// 测试关联数据任务的内容
PushContentApi pushContentApi = new PushContentApi();
pushContentApi.setContent("测试内容");
pushContentApi.setActivityId(201l);
pushContentApi.setCreateTime(new Date());
pushContentApi.setCreatorId(-1l);
pushContentApi.setCreatorName("测试用户");
pushContentApi.setTaskId(MockDataTaskManager.DATA_TASK_ID);
pushContentApi.setUpdateTime(new Date());
pushContentApi.setUpdatorId(-1l);
pushContentApi.setUpdatorName("测试用户");
pushContentSoaService.savePushContent(pushContentApi);
// 测试不关联数据任务的内容
PushContentApi pushContentApi1 = new PushContentApi();
pushContentApi1.setContent("测试内容");
pushContentApi1.setCreateTime(new Date());
pushContentApi1.setCreatorId(-1l);
pushContentApi1.setCreatorName("测试用户");
pushContentApi1.setTestMobiles("13810001000,13810001001");
pushContentApi1.setUpdateTime(new Date());
pushContentApi1.setUpdatorId(-1l);
pushContentApi1.setUpdatorName("测试用户");
pushContentSoaService.savePushContent(pushContentApi1);
}
验证的逻辑都放在了mock出来的manager的接口实现里，跑一下这个单元测试，就能验证正确的逻辑了。这个只是很简单的代码思路，业务层接口实现里如果有很多校验规则与逻辑的话，还需要分别测试。如果要测试真实的manager接口实现，那又再单独写他的单元测试了，但是应该是与业务层的单元测试完全解耦的。
总结一下，单元测试要想写好，必须要灵活运用解构技巧，关注点始终放在各层的分工与职责上。而且有了这种思想，就能实现真正的测试驱动开发了（测试用例先行，你懂的）。
