自動化單元測試實踐之路(5)

　　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