核心思想

• Rules
  • Write new code only if you first have a failing automated test.
  • Eliminate duplication.
• Red/green/refactor. The TDDs mantra.
  • Red: write a little test that doesn’t work, perhaps doesn’t even compile at first
  • Green: make the test work quickly, committing whatever sins necessary in the process
  • Refactor: eliminate all the duplication created in just getting the test to work

By Example

• 首先，來(lái)了一個(gè)需求，不是思考需要一個(gè)什么對(duì)象，需要一個(gè)什么方法，而是需要一個(gè)什么測(cè)試，來(lái)驗(yàn)證我們的實(shí)現(xiàn)是正確的
• 更進(jìn)一步的，是需求可測(cè)試化：需求不是一句話，而是一個(gè)todo list，其實(shí)就是所有的（盡量）測(cè)例，有什么需求都通過(guò)測(cè)例來(lái)描述，在什么情況下軟件應(yīng)該是什么行為，要細(xì)化到可以直接翻譯為代碼
• 思考需要解決的問(wèn)題的時(shí)候，都是以：我需要什么樣的測(cè)試以驗(yàn)證實(shí)現(xiàn)正確開(kāi)始，而不是如何實(shí)現(xiàn)
• 測(cè)試化的需求可能繁簡(jiǎn)程度不一，那么就需要先從簡(jiǎn)單的開(kāi)始，同時(shí)學(xué)會(huì)把復(fù)雜的測(cè)例拆分為簡(jiǎn)單的測(cè)例
• 為尚不存在的代碼編寫(xiě)測(cè)例時(shí)，首先假設(shè)它有完美的接口滿足其功能，同時(shí)先不要管封裝、數(shù)據(jù)類型等復(fù)雜問(wèn)題，讓測(cè)試代碼盡量簡(jiǎn)單，例如：

    public void testMultiplication() { 
        Dollar five= new Dollar(5); 
        five.times(2);
        assertEquals(10, five.amount);
    }

• 一步一步來(lái)，先讓讓測(cè)例寫(xiě)出來(lái)，但同時(shí)要記下需要改善的地方，先寫(xiě)出一個(gè)可以跑，但是失敗的測(cè)例，然后再逐步實(shí)現(xiàn)、逐步改善測(cè)例與實(shí)現(xiàn)
• 編寫(xiě)的測(cè)例首先應(yīng)該是不能編譯的，借助IDE，我們可以很方便的添加相應(yīng)的類、成員、方法，使得測(cè)例能夠編譯，注意！這一步不要加入任何實(shí)現(xiàn)，僅僅讓測(cè)例可編譯，一旦加入了實(shí)現(xiàn)，就容易沉浸在實(shí)現(xiàn)中了
• 測(cè)例運(yùn)行起來(lái)當(dāng)然是失敗的，但這是巨大的進(jìn)步！從“實(shí)現(xiàn)XX功能”，到“讓這個(gè)測(cè)例通過(guò)”，簡(jiǎn)單了無(wú)數(shù)倍！

• TDD五部曲，有點(diǎn)naive，但值得借鑒

  • Add a little test
  • Run all tests and fail
  • Make a little change，最小改動(dòng)，例如直接把a(bǔ)mount初始值賦值為10
  • Run the tests and succeed
  • Refactor to remove duplication
• 好代碼的“天敵”：依賴與重復(fù)
  • 依賴：上面的測(cè)例顯然依賴于實(shí)現(xiàn)，改實(shí)現(xiàn)就必須要改測(cè)例，而這并不是我們想要的，我們的目標(biāo)是編寫(xiě)有意義（能驗(yàn)證實(shí)現(xiàn)正確性）的測(cè)例，但是變更實(shí)現(xiàn)細(xì)節(jié)不需要修改測(cè)例，目前看來(lái)有點(diǎn)難；實(shí)際開(kāi)發(fā)也是如此，如果代碼依賴于某一組件的實(shí)現(xiàn)細(xì)節(jié)，那以后想要替換另一組件，就很麻煩；
  • 重復(fù)：If dependency is the problem, duplication is the symptom. 代碼的重復(fù)往往起源于重復(fù)的邏輯，例如邏輯一樣的表達(dá)式出現(xiàn)在多個(gè)地方；而對(duì)象（面向?qū)ο螅┨焐褪怯脕?lái)把重復(fù)的邏輯抽象出來(lái)的，別辜負(fù)了對(duì)象；
  • 還好，在程序中，消除重復(fù)，就能消除依賴
• 找到重復(fù)，消除重復(fù)
  • 和實(shí)際代碼的重復(fù)不太一樣，不是基本相同的邏輯在重復(fù)；測(cè)例與實(shí)現(xiàn)的重復(fù)在于數(shù)據(jù)的重復(fù)，例如直接int amount= 10;和測(cè)例的測(cè)試數(shù)據(jù)是重復(fù)的
  • 書(shū)中的例子非常簡(jiǎn)單，但道理很深刻：TDD不是關(guān)于一些小的、簡(jiǎn)單的步驟，而是關(guān)于如何能夠把難題拆分為小的、簡(jiǎn)單的步驟！
  • 其實(shí)當(dāng)能夠把每一步拆分得不能再小時(shí)，就表明對(duì)問(wèn)題的理解達(dá)到了一定的程度，此時(shí)當(dāng)然知道應(yīng)該把問(wèn)題拆分為何種粒度的子問(wèn)題，保持思考！
• 讓測(cè)例能夠通過(guò)的合適的Dollar類代碼，誰(shuí)都會(huì)寫(xiě)，但是這個(gè)思考的過(guò)程卻未必，而這正是踐行TDD應(yīng)該注意的地方！

• 完成上步后，就是時(shí)候考慮實(shí)現(xiàn)的優(yōu)雅性了，將其也加入到todo list中吧！

• 一步一步來(lái)！