敏捷-測試先行方法介紹

第第頁敏捷——測試先行方法介紹敏捷——測試先行方法介紹

發(fā)表于：2023-08-17來源：不祥：junJZ_2023點(diǎn)擊數(shù)：標(biāo)簽：敏捷測試

是的，現(xiàn)在肯定有讀者會(huì)這樣說了：“我只在產(chǎn)品發(fā)品之前寫測試?！庇行┤丝赡軙?huì)竊笑，對(duì)質(zhì)量保證部門說三道四。還有一些人作為項(xiàng)目經(jīng)理可能會(huì)添油加醋地說：“我們可不會(huì)浪費(fèi)時(shí)間寫測試代碼;我們還得寫真正的代碼呢?！蹦敲?，采用TDD到底是什么意思呢?

是的，現(xiàn)在肯定有讀者會(huì)這樣說了："我只在產(chǎn)品發(fā)品之前寫（測試）。'有些人可能會(huì)竊笑，對(duì)質(zhì)量保證部門說三道四。還有一些人作為項(xiàng)目經(jīng)理可能會(huì)添油加醋地說："我們可不會(huì)浪費(fèi)時(shí)間寫（測試）代碼;我們還得寫真正的代碼呢。'那么，采用TDD到底是什么意思呢?

TDD產(chǎn)生于敏捷（開發(fā)）運(yùn)動(dòng)，特別是極限（編程）(extremeprogramming，XP)，而且TDD正是XP的一個(gè)核心原則。推崇TDD的人認(rèn)為，不應(yīng)該完成（開發(fā)）之后再寫測試，這通常只是"馬后炮'，而應(yīng)當(dāng)在寫代碼之前先寫測試。測試本質(zhì)上相當(dāng)于設(shè)計(jì)文檔，而不是花大量時(shí)間去擺弄一個(gè)復(fù)雜的圖形化工具，你要直接在代碼中"擬畫'一個(gè)類。開始時(shí)先為一些小功能塊編寫測試。在有些語言下，你寫的測試甚至不能編譯，因?yàn)樗玫念惿胁淮嬖凇Ｒ坏┙⒘藴y試，就可以運(yùn)行這個(gè)測試(當(dāng)然，此時(shí)運(yùn)行測試會(huì)失敗)。然后再編寫最少量的代碼，以便測試通過。接下來再重構(gòu)代碼，并增加更多的測試。

通常可以使用測試框架來幫助編寫（自動(dòng)化）測試。最著名的框架是JUnit，不過現(xiàn)在已經(jīng)有很多xUnit項(xiàng)目，可以簡化在各種語言下測試的創(chuàng)建。一般地，這些框架都建立在斷言(assert)基礎(chǔ)上。開發(fā)人員編寫（測試方法），將調(diào)用方法的實(shí)際結(jié)果與期望結(jié)果進(jìn)行比較。當(dāng)然，可以人工地檢查一個(gè)日志文件或用戶界面來完成這些比較，但是，用計(jì)算機(jī)完成數(shù)據(jù)比較不僅速度快，也更準(zhǔn)確。另外，就算是讓計(jì)算機(jī)把同樣的測試運(yùn)行上1500次，它們也不會(huì)嫌煩，如果是人可做不到這一點(diǎn)。

有了JUnit和其他測試框架，編寫和運(yùn)行測試變得相當(dāng)簡單。這就能鼓勵(lì)開發(fā)人員創(chuàng)建大量測試(往往能更完備地覆蓋各種測試情況)，而且會(huì)樂于經(jīng)常運(yùn)行這些測試(可以更快地幫助開發(fā)人員找到（bug）)。在許多情況下，如果項(xiàng)目中采用了TDD，測試代碼往往與生產(chǎn)代碼一樣多!

使用TDD可以帶來許多重要的好處：

提供明確的目標(biāo)：你很清楚，一旦結(jié)束(也就是一旦測試通過)，你的工作就完成了(假設(shè)你的測試寫得很好)。測試會(huì)為代碼建立一個(gè)自然的邊界，使你把重點(diǎn)集中在當(dāng)前任務(wù)上。一旦測試通過，就有確切的證據(jù)證明你的代碼能工作。相對(duì)于人工地測試用戶界面或者比較日志文件中的結(jié)果，在一個(gè)xUnit框架中運(yùn)行（自動(dòng)化測試），速度要快幾個(gè)數(shù)量級(jí)。大多數(shù)xUnit測試的運(yùn)行只需幾微秒，而且大多數(shù)采用TDD的人都會(huì)一天運(yùn)行數(shù)次測試。在許多開發(fā)小組中，將代碼簽入源代碼樹之前，代碼必須成功地通過測試。

提供文檔：你是不是經(jīng)常遇到看不懂的代碼?這些代碼可能沒有任何文檔說明，而且開發(fā)代碼的人可能早就走了(或者度假去了)。當(dāng)然，看到這種代碼的時(shí)間往往也很不合時(shí)宜，可能是凌晨3點(diǎn)，也可能有位副總在你旁邊大聲催促著趕快解決昨天的問題，這樣要想花些時(shí)間來明白原的意圖就更困難了。我們見過一些好的（單元測試）文檔，它們會(huì)指出系統(tǒng)要做什么。測試就像原開發(fā)人員留下的記號(hào)，可以展示他們的類具體是怎么工作的。

改善設(shè)計(jì)：編寫測試能改善設(shè)計(jì)。測試有助于你從界面的角度思考，測試框架也是代碼的客戶。測試能讓你考慮得更簡單。如果你確實(shí)遵循了"盡量簡單而且行之有效'的原則，就不會(huì)寫出篇幅達(dá)幾頁的復(fù)雜算法。要測試的代碼通常依賴性更低，而且相互之間沒有緊密的聯(lián)系，因?yàn)檫@樣測試起來更容易。當(dāng)然，還有一個(gè)額外的作用，修改起來也會(huì)更容易!

鼓勵(lì)重構(gòu)：利用一套健壯的測試集，你能根據(jù)需要進(jìn)行重構(gòu)。你是不是經(jīng)常遇到一些不知是否該修改的代碼?種種顧慮讓你行動(dòng)遲緩，過于保守，因?yàn)槟悴荒鼙ＷC所做的修改會(huì)不會(huì)破壞系統(tǒng)。如果有一套好的單元測試集，就能放心地進(jìn)行重構(gòu)，同時(shí)能保證你的代碼依然簡潔。

提高速度：編寫這么多測試會(huì)不會(huì)使開發(fā)速度減慢呢?人們經(jīng)常會(huì)以速度(或開發(fā)開銷)作為反對(duì)進(jìn)行TDD和使用xUnit框架的理由。所有新的工具都會(huì)有學(xué)習(xí)曲線，但是一旦開發(fā)人員適應(yīng)了他們選擇的框架(通常只需很短的時(shí)間)，開發(fā)速度實(shí)際上會(huì)加快。一個(gè)完備的單元測試集提供了一種方法對(duì)系統(tǒng)完成（回歸）測試，這說明，增加一個(gè)新特性之后，你不必因?yàn)閼岩伤鼤?huì)不會(huì)破壞原系統(tǒng)而寢食難安。

提供反饋：單元測試還有一個(gè)經(jīng)常被忽略的優(yōu)點(diǎn)，即開發(fā)的節(jié)奏。盡管看上去好像無關(guān)緊要，但通過測試之后你會(huì)有一種完成任務(wù)的成就感!你不會(huì)成天地修改代碼而沒有任何反饋，這種測試代碼測試的方法會(huì)鼓勵(lì)你動(dòng)作幅度小一些，通常修改一次代碼的時(shí)間僅幾分鐘而已。這樣你不會(huì)一下子看到冒出一大堆的新特性，而只是讓代碼基一次前進(jìn)一小步。

從我們的經(jīng)驗(yàn)看，測試是會(huì)傳染的，你可能會(huì)慢慢上癮。一開始，許多開