BillingBusinessManagerUnitTest类:
//引入包忽略... public class BillingBusinessManagerUnitTest extends MockitoTestContext { @InjectMocks private BillingBusinessManager sv; @Mock private BillingBusinessDAO billingBusinessDAO; @Test public void testGetBusinessesByIds() { List<BusinessVO> expected = ListUtil.toList(new BusinessVO(1l, "a", "b")); //简洁的语法如下所示 when(billingBusinessDAO.getBusinessbyIds(anyListOf(Long.class))).thenReturn(expected); List<Long> businessIds = ListUtil.toList(TestConstants.BUSINESS_ID_HTTP_WEB_CACHE); List<BusinessVO> actual = sv.getBusinessesByIds(businessIds); Assert.assertEquals(expected, actual); } } |
更多Mockito的使用,可以参考官网:http://code.google.com/p/mockito/
6 总结
如何加强开发过程中的自测环节,一直都是个头痛的问题,开发的代码质量究竟如何?模块之间的质量究竟如何?回归测试的效率如何?重构之后,如何快速验证模块的有效性?
这些在没有做自动化单元测试之前,都是难以考究的问题。唯有通过数据去衡量,横向对比多个版本的构建分析结果,才能够发现整个项目质量的趋势,是提升了,还是下降了,这样开发、测试人员才能够有信心做出恰当的判断。
当然,单元测试也不是银弹,即便项目的覆盖率达到100%,也不能表明产品质量没有任何问题,不会产生任何缺陷。重点在于确保单元测试环节的实施,可以提前释放压力、风险、暴露问题等多个方面,改变以往没有单元测试,所有问题都集中到最后爆发的弊端。
最后,用一张图来做个对比:
图-6-1-使用前后对比
增加单元测试之后:
开发效率有望提升5-20%;重构、回归测试效率提升10%,降低出错的几率,总体代码质量提升;
在开发过程中暴露更多问题,将风险和压力提前释放,持续构建促使开发重视代码质量;
UnitTest质量对于团队来说,是可视化了,交付的是有质量的产品,而不是数量;
原文转自:http://www.uml.org.cn/Test/201407281.asp