建站
咨詢
售后
建站咨詢
新聞中心
在上一篇文章《讓我們再聊聊TDD》里面，通過對DHH的文章以及DHH和Kent Beck等討論的分析，我闡述了對TDD的理解和分類，現(xiàn)在來繼續(xù)聊聊TDD的實施和分層。
現(xiàn)在還有非常多的軟件工程師在質(zhì)疑TDD的可行性，比如太難不會、成本太高無法推動、意義不是很大等，但是他們卻一直都在做著TDD，只不過沒有意識到而已，這便是“不識廬山真面目，只緣身在此山中”。
TDD的實施一般分為思維層面和技術層面。一般來說，思維層面上的實施成本較低、容易接受，但是缺點很多，比如難以傳遞、難以持續(xù)獲得快速反饋等;而技術層面上的實施一般成本較高、不容易被人接受，但是優(yōu)點更多，比如可以獲得快速反饋、更容易傳遞和協(xié)作等。而現(xiàn)實世界中TDD的實施一般分為三個階段，即無意識的TDD、被動通過技術實現(xiàn)的TDD、以及有意識和主動通過技術實現(xiàn)的TDD。
1. ***階段：無意識的TDD
對于軟件開發(fā)人員，當他們拿到一個新的軟件需求時，首先會思考如何實現(xiàn)，其中包括當前軟件架構(gòu)、業(yè)務分解、實現(xiàn)設計、代碼分層、代碼實現(xiàn)等。然后通過思考和設計所得到的產(chǎn)出物來驅(qū)動代碼實現(xiàn)，進而在代碼實現(xiàn)中會思考如何通過一個或多個函數(shù)或者算法來實現(xiàn)業(yè)務邏輯。所以軟件系統(tǒng)的實現(xiàn)要先通過意識層面的思考，再進行技術層面的工作。
當開發(fā)人員思考和設計這些函數(shù)或者方法的時候，一般都會思考它們有哪些參數(shù)，然后想象將這些參數(shù)換成真實的數(shù)據(jù)后傳遞進去，會得到怎樣的返回值。好一點的開發(fā)人員會思考如何處理異常輸入和異常返回值。
這類思考其實已經(jīng)是意識思維上的TDD，它幫助開發(fā)人員先在大腦里面設計并驗證代碼實現(xiàn)，甚至幫助其重構(gòu)代碼。所以很多開發(fā)人員都在無意識的情況下做著TDD。
比如在一個銀行系統(tǒng)里面，開發(fā)人員拿到一個需求，需要開發(fā)一個通過手機APP轉(zhuǎn)賬的功能。
首先開發(fā)人員會基于當前的軟件架構(gòu)思考：是開發(fā)一個全新的模塊來處理這個業(yè)務?還是基于當前架構(gòu)中的某個模塊來添加代碼進行處理?
當確定架構(gòu)和設計之后，就開始思考具體的代碼實現(xiàn)，比如類的設計、方法的設計或者函數(shù)的設計等。當開發(fā)“將錢從原帳號轉(zhuǎn)出”這個功能前，開發(fā)人員會思考：這個功能需要支持當錢從原帳號中轉(zhuǎn)出成功后，原帳號中的余額等于原始余額減去轉(zhuǎn)出金額。進一步有些程序員還會設計一些用來驗證功能的實例，比如帳號中的原始余額是999.99，轉(zhuǎn)出111.11，那么剩余的金額就應該是888.88。
在這樣思考之后，開發(fā)人員便開始根據(jù)自己大腦中的測試邏輯和用例來驅(qū)動和輔助開發(fā)過程。在代碼開發(fā)完畢之后還會想一些辦法來驗證一下所實現(xiàn)的功能是否符合預期，比如人工使用之前的或者新的測試用例再測試一下。如果驗證正確，就會認為自己開發(fā)的功能正確了，并交給測試人員進行測試。
其實開發(fā)人員在開發(fā)前思考測試邏輯和用例的過程就是在做TDD了。
很多做業(yè)務分析的BA和測試分析前移的QA也同樣在無意識的做著TDD(注：在前一篇文章中已說明TDD包含ATDD)，比如分析驗收條件、寫出驗收文檔等。只不過這些AC和驗收文檔可能寫得不是很明確或者不是很好，比如不是實例化需求等，但是本質(zhì)上已經(jīng)是TDD了。
只不過是初級的無意識的TDD，可能有的人做得好，有的人做得不好，而且沒有明確的產(chǎn)出來協(xié)助和規(guī)范這個測試驅(qū)動開發(fā)方式，也缺乏快速反饋、度量、傳遞和協(xié)作等。因此從無意識到有意識將是做好TDD的一個重要過渡。
2. 第二階段：被動通過技術實現(xiàn)TDD
當有一部分軟件工程師意識到了TDD的意義和普遍存在性之后，就開始準備解決思維上的TDD的缺點。而解決這些問題的方法就是在技術層面上用代碼來實現(xiàn)TDD，用明確的代碼來協(xié)助和規(guī)范開發(fā)人員的測試驅(qū)動開發(fā)行為，來度量他對業(yè)務邏輯以及代碼實現(xiàn)的理解度。通過將他的理解傳遞給以后的維護人員，讓他的理解能重復被使用，以及和其他人協(xié)作開發(fā)。
但是現(xiàn)實中很多開發(fā)人員的認識不足以及技術能力不夠，就算管理層支持并且主動推動TDD，最終
由于開發(fā)人員設計和選取的測試用例合理性很差，導致驅(qū)動出來的代碼有效性差，測試用例無法體現(xiàn)出SBE(Specification by example)導致易讀性差，對于自動化測試框架和測試編寫不熟悉導致開發(fā)速度很慢等，往往是被動的在技術層面上去實現(xiàn)TDD，所以出現(xiàn)了各種怨言，各種抵觸，進而導致技術層面上的TDD很難以大規(guī)模實施。
由于意識層面上的難易程度和工作量都比技術層面上相對較小，所以前者實施起來相對容易一些，而后者則相對較難，所以如果通過了各種手段強行實施TDD，而沒有主動去擺正做TDD的意識，甚至沒有足夠的技術能力，那么這樣的TDD就是一個倒三角，非常容易倒塌。
TDD倒三角
所以，如果不希望技術層面上的TDD隨時倒塌，就需要把這個倒三角補全，才能更好的、長久的實施TDD。
3. 第三階段：有意識和主動通過技術實現(xiàn)TDD
為了大規(guī)模以及有效的實施TDD，首先要突破思維意識的局限，認識到TDD的普遍存在性和適用性，不要害怕和排斥TDD這種思維和開發(fā)模式。
其次要主動學習，并刻意練習TDD的技術實現(xiàn)，提升自己的技術能力，從而在技術層面能更容易的實現(xiàn)TDD，擺脫被動TDD的困境。其中學習的方法包括閱讀TDD相關的書籍和文章，書籍包括《測試驅(qū)動開發(fā)》、《重構(gòu)》、《BDD In Action》以及《系統(tǒng)思考》等，從而充分理解TDD優(yōu)點和局限。
對于刻意練習，一定要長時間堅持去做，讓其成為一種習慣。如果在項目中沒有合適的環(huán)境去練習，還可以通過一些第三方的TDD練習系統(tǒng)去做刻意練習，比如Cyber-dojo。只有大量的刻意練習才能讓你在真實的代碼編寫過程中去思考和理解TDD，去運用你通過學習得到的知識，最終才能做到有意識和主動的通過技術去實現(xiàn)TDD，TDD的倒三角才能變成一個穩(wěn)定的磚塊，然后哪里需要往哪里搬。
TDD磚塊
4. 總結(jié)
綜上，大部分開發(fā)人員都應該在做TDD，只不過他們是無意識的或者被動的去實現(xiàn)的，只有少部分是有意識和主動的去實現(xiàn)的。
既然人人都在做TDD，那么我們?yōu)槭裁床荒芎秃诳偷蹏锩娴腘eo一樣選擇紅色藥丸來認清楚現(xiàn)實，主動擁抱TDD，并通過大量的刻意練習去改變自己的工作習慣，讓TDD成為自己工作習慣的一部分，這樣才能更好的提升軟件質(zhì)量，大大降低軟件維護成本。不管你信不信，反正我信了。
新聞標題：讓我們再聊聊TDD續(xù)——人人都在做TDD
文章轉(zhuǎn)載：http://m.5511xx.com/article/cdhcepi.html
