自动化单元测试实践之路(5)

发表于:2014-07-29来源:uml.org.cn作者:李乐点击数: 标签:
BillingBusinessManagerUnitTest类: //引入包忽略...public class BillingBusinessManagerUnitTest extends MockitoTestContext { @InjectMocks private BillingBusinessManager sv; @Mock private BillingB

  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