單元測試是工程交付前質(zhì)量保障的第一環(huán)，也無疑是軟件工程質(zhì)量保障的重要基石，有效的單元測試能夠提前發(fā)現(xiàn)90%以上的代碼Bug問題，同時也能防止代碼的腐化，在工程重構(gòu)演進時起到至關(guān)重要的作用。

為什么需要單元測試

縱觀優(yōu)秀的開源工程，完備的單元測試總是必須的條件。通過這些單元測試，我們可以充分了解代碼中相關(guān)類和方法的作用和核心邏輯，熟悉各種場景的運行情況。同時也因為有了單元測試，開源作者在接受各種feature的代碼提交時才有穩(wěn)定安全的保障。其實單元測試的重要性所有開發(fā)同學應(yīng)該都了然于胸，同樣TDD(測試驅(qū)動開發(fā))也不是一個新的概念，但是真當我們落地實踐時，又總會找出各種各樣的理由來勸服自己下次一定好好寫單元測試，這一次先放過自己。這些理由無外乎，開發(fā)周期太緊了; 測試同學能保證功能正確性;寫單元測試代碼量比業(yè)務(wù)代碼還大; 又不是不能跑。所以雖然我們總是在追逐工程師文化，卻又時不時放縱在放棄工程師底蘊的路上。

單元測試是工程交付前質(zhì)量保障的第一環(huán)，也無疑是軟件工程質(zhì)量保障的重要基石，有效的單元測試能夠提前發(fā)現(xiàn)90%以上的代碼Bug問題，同時也能防止代碼的腐化，在工程重構(gòu)演進時起到至關(guān)重要的作用。

怎么寫單元測試

?  好的單元測試的幾個要點

摘自阿里巴巴開發(fā)規(guī)約

1. 單元測試必須遵守AIR原則，單元測試必須具備Automatic(自動化)，Independent(獨立性)，Repeatable(可重復(fù))性；
2. 單元測試應(yīng)該是全自動執(zhí)行的，并且非交互式的。測試用例通常是被定期執(zhí)行的，執(zhí)行過程必須完全自動化才有意義。輸出結(jié)果需要人工檢查的測試不是一個好的單元測試；
3. 單元測試要保證測試粒度足夠小。單元測試測試粒度足夠小，有助于精確定位問題。單測粒度至多是類級別，一般是方法級別；
4. 單元測試要遵守BCDE原則，Border，邊界值測試，包括循環(huán)邊界、特殊取值、特殊時間點、數(shù)據(jù)順序等；Correct，正確的輸入，并得到預(yù)期的結(jié)果；Design，與設(shè)計文檔相結(jié)合，來編寫單元測試；Error，強制錯誤信息輸入（如：非法數(shù)據(jù)、異常流程、非業(yè)務(wù)允許輸入等），并得到預(yù)期的結(jié)果；
5. 核心業(yè)務(wù)、核心應(yīng)用、核心模塊的增量代碼要確保單元測試通過；

?  單元測試編碼范式

這里主要以Mockito單元測試框架為模版

1. Mock :
   通過when().thenReturn/thenAnswer/thenThrow 或者doReturn().when()等mock方式將依賴類方法進行模擬，模擬服務(wù)依賴或者中間結(jié)果
2. DO :  
   調(diào)用被測試類方法，執(zhí)行測試鏈路
3. Verify :  
   校驗執(zhí)行結(jié)果正確性，通過Assert校驗數(shù)據(jù)結(jié)果準確，通過Verify校驗鏈路執(zhí)行準確，通過expected=Exception.class校驗異常鏈路

public class Test {
    // 0. 依賴類
    @Mock
    DependencyClass dependencyClass;
    // 0. 待測試類
    @InjectMocks
    TestClass testClass;


    @Before
    public void setUp() {
        MockitoAnnotations.initMocks(this);
    }


    @Test
    public void testMethod() {
        // 1. Mock, 依賴方法，構(gòu)造中間層數(shù)據(jù)
        when(dependencyClass.someMehod(any())).thenReturn(mockData());
        // 2. Do, 調(diào)用被測試類
        Result result = testClass.testMehod();
        // 3. Verify, 校驗結(jié)果數(shù)據(jù)
        Assert.assertEquals("some expected result string", result.getModel());
    }
}

當然寫單元測試用例雖然套路比較模版化，但是我們也要充分利用單元測試框架（Junit/Mockito/PowerMock/Spock），掌握其中的一些技巧，才能寫出快準狠的單元測試用例，這也是研發(fā)同學必須要掌握的基本功。關(guān)于如何利用單元測試框架這里不再贅述（詳細可以參考阿里技術(shù)《Java編程技巧之單元測試用例編寫流程》）。

?  單元測試編碼提效

IDEA上有很多單元測試插件，能夠半自動化生成單元測試類文件，這里重點推薦TestMe插件。TestMe插件可以智能分析被測試類的依賴類，結(jié)合Mockito+Junit等單元測試框架，生成Mock/InjectMocks依賴關(guān)系，自動生成單元測試類。

假設(shè)業(yè)務(wù)代碼如下：

@Component
public class DefaultMemberManager implements MemberManager {
    @Autowired
    private MemberDAO memberDAO;
    @Autowired
    private CacheManager cacheManager;


    @Override
    public Date queryActivationTime(long userId) {
        Date activationTime = cacheManager.getActivationTime(userId);
        if (activationTime == null) {
            MemberDO memberDO = memberDAO.queryByUserId(userId);
            if (memberDO != null) {
                cacheManager.saveActivationTime(userId, memberDO.getActiveTime());
                activationTime = memberDO.getActiveTime();
            }
        }
        return activationTime;
    }
}

則通過TestMe快捷鍵COMMOND+N, 可以極速自動生成如下的單元測試類

public class DefaultMemberManagerTest {
    @Mock
    MemberDAO memberDAO;
    @Mock
    CacheManager cacheManager;
    @InjectMocks
    DefaultMemberManager defaultMemberManager;


    @Before
    public void setUp() {
        MockitoAnnotations.initMocks(this);
    }


    @Test
    public void testQueryActivationTime() throws Exception {
        when(memberDAO.queryByUserId(anyLong())).thenReturn(null);
        when(cacheManager.getActivationTime(anyLong())).thenReturn(
            new GregorianCalendar(2022, Calendar.MARCH, 5, 23, 2).getTime());
        Date result = defaultMemberManager.queryActivationTime(0L);
        Assert.assertEquals(new GregorianCalendar(2022, Calendar.MARCH, 5, 23, 2).getTime(), result);
    }
}

團隊單元測試建設(shè)

?  覆蓋率概念

覆蓋率是類JaCoCo插件通過javaagent掛載的方式，在單元測試命令運行時執(zhí)行代碼覆蓋率檢測，計算單元測試執(zhí)行過程中所覆蓋的代碼比例來生成覆蓋率。常見的覆蓋率指標，又可進一步細分為語句覆蓋率，條件覆蓋率，分支覆蓋率，路徑覆蓋率等。這里我們當前更為關(guān)注語句覆蓋率和分支覆蓋率，尤其是增量代碼的覆蓋率，更能體現(xiàn)變更代碼的單元測試覆蓋情況。

?  如何進行單元測試

這里我們借助于阿里研發(fā)平臺Aone的測試實驗室功能，Aone實驗室支持測試任務(wù)插件的編排組合，通過獨立的測試資源執(zhí)行測試任務(wù)。所以我們將代碼拉取插件，單元測試插件和覆蓋率計算插件進行編排配置，形成最終的執(zhí)行流：拉取代碼；執(zhí)行單元測試命令；單元測試結(jié)果解析；計算覆蓋率。最終完成整個工程的單元測試覆蓋率計算。

單元測試覆蓋率結(jié)果示例如下：

?  什么時候觸發(fā)單元測試

單元測試任務(wù)主要通過持續(xù)交付流水線pipeline來集成，當前幾個主要觸發(fā)策略如下：

1. 代碼提交時，保證單元測試執(zhí)行及時性
2. 代碼審核時，保證代碼審核通過的代碼分支符合單元測試標準
3. 發(fā)布流程中，保證最終集成發(fā)布的所有分支代碼符合單元測試標準

?  單元測試覆蓋率卡點

用戶平臺技術(shù)團隊單元測試規(guī)范如下:

1. 單元測試用例通過率為100%
2. 單元測試增量代碼行覆蓋率為85%
3. 代碼規(guī)范掃描增量問題總數(shù)為0個

?  單元測試覆蓋率報表

為了更好的衡量單元測試的覆蓋率情況，我們采用報表的形式統(tǒng)計每個應(yīng)用，每個團隊的代碼單元測試覆蓋率。

總結(jié)

當前團隊內(nèi)各應(yīng)用（除邊緣應(yīng)用外）的單元測試增量代碼覆蓋率在2022年已經(jīng)全部達到85%標準，最新平均增量代碼行覆蓋率達到88%，整體全量代碼覆蓋率平均提高20%。誠然單元測試覆蓋率的提高不是最終的目的，覆蓋率高不能完全代表工程質(zhì)量高，但是一個沒有單元測試或者單元測試覆蓋率低的工程，其代碼質(zhì)量和穩(wěn)定性必然不高。同時團隊內(nèi)研發(fā)同學對單元測試也有了新的認識，自測和提測質(zhì)量顯著提升，全年未發(fā)生由于代碼質(zhì)量產(chǎn)生的線上故障，有效提升了工程質(zhì)量和服務(wù)穩(wěn)定性。

后續(xù)規(guī)劃，持續(xù)優(yōu)化單元測試質(zhì)量，提升分支覆蓋率，優(yōu)化邊界異常覆蓋；關(guān)注單元測試編碼效率的提升，優(yōu)化測試用例和測試數(shù)據(jù)分離；關(guān)注核心鏈路單元測試覆蓋率；熟練將TDD思維運用到業(yè)務(wù)開發(fā)過程中。

團隊介紹

大淘寶技術(shù)-用戶平臺技術(shù)團隊是一支集研發(fā)、數(shù)據(jù)、算法一體的團隊，負責淘系的用戶增長，游戲互動，平臺會員和私域運營等消費者核心業(yè)務(wù)。團隊承擔捍衛(wèi)電商主板塊增長的重要使命，是阿里核心電商戰(zhàn)場的參與者，用持續(xù)的技術(shù)創(chuàng)新來驅(qū)動阿里電商引擎的穩(wěn)步前行。

這是一支年輕開放的團隊，在這里你將收獲超大規(guī)模高并發(fā)場景的架構(gòu)設(shè)計能力，洞悉用戶增長最前沿的實踐方法，在數(shù)字化時代收獲最核心的競爭力。團隊技術(shù)氛圍濃厚，倡導創(chuàng)新和工程師文化，鼓勵用數(shù)據(jù)和代碼發(fā)現(xiàn)解決問題。團隊研發(fā)流程規(guī)范，代碼質(zhì)量高，學習成長速度快。