當(dāng)談到測試驅(qū)動開發(fā)(以下簡稱為“TDD”)時,業(yè)內(nèi)工程師對它有一定程度的了解,并且TDD的優(yōu)勢得到了普遍認(rèn)可。一些研究機(jī)構(gòu)對微軟和IBM的八個開發(fā)團(tuán)隊進(jìn)行了對比測試,發(fā)現(xiàn)使用TDD的團(tuán)隊與不使用TDD的團(tuán)隊相比,問題發(fā)生率降低了40%-90%。在結(jié)對編程的相關(guān)實驗中,使用TDD的組的黑盒測試通過率比不使用TDD的組高18%,效果相當(dāng)明顯。然而,與我們在日常生活中所接觸到的實際工作相比,TDD很少被使用,它的價值也被代碼農(nóng)民所混淆。甚至有大咖啡在網(wǎng)上寫文章,公開討論反對它的意見。為什么?不久前,我在融云的一個項目中碰巧有一個小規(guī)模的實踐,所以我試圖結(jié)合各方的觀點,大膽地談?wù)勎易约旱慕?jīng)歷。首先,什么是TDD?TDD首先由肯特·貝克提出,并在他的書《《Test-Driven Development By Example》》中進(jìn)行了詳細(xì)的解釋(肯特·貝克也是極限編程概念的作者)。正如書中所述,TDD是一種以測試為開發(fā)過程中心的軟件工程方法,它要求在編寫任何產(chǎn)品代碼之前,首先要編寫用于定義產(chǎn)品代碼行為的測試,編寫的產(chǎn)品代碼應(yīng)該以通過測試為目標(biāo),從而構(gòu)建簡單、清晰、高質(zhì)量的代碼。測試是保證軟件質(zhì)量的重要手段。一個公司的R&D部門通常有很大比例的測試團(tuán)隊作為質(zhì)量保證的堅實后盾。那么,作為一個開發(fā)人員,你能只關(guān)心編寫代碼的進(jìn)度,并且在運(yùn)行幾次之后提交代碼而沒有任何問題嗎?當(dāng)初始條件稍有變化或者外部因素如壓力和并發(fā)性稍有變化時,這樣的程序會崩潰嗎?一些團(tuán)隊將制定規(guī)則和條例,要求為完成的代碼編寫測試用例,這些代碼必須在提交之前通過。這可能會在一定程度上改善情況,但實際效果真的那么明顯嗎?我聽到有人抱怨說,在代碼完成后編寫測試用例是浪費(fèi)時間,因為邏輯趨勢已經(jīng)被很好地理解了,測試中不會有重大錯誤。那時最好多寫幾行代碼,因為有一個測試團(tuán)隊。乍一看,這聽起來很合理,但仔細(xì)想想,你實際上是在逃避責(zé)任,浪費(fèi)公司資源。確保軟件質(zhì)量的最好方法是什么?讓我們看看TDD是如何工作的。如前所述,TDD的本質(zhì)在于將測試放在前面。這個看似微不足道的變化會帶來什么樣的化學(xué)反應(yīng)?首先,目的可以明確界定。在編寫產(chǎn)品代碼之前,您必須首先考慮這部分邏輯的輸入和輸出是什么,然后寫
行業(yè)資訊
[融云分析]關(guān)于測試驅(qū)動開發(fā)的一些見解
瀏覽:358 時間:2023-3-13