核心思想

• 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

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

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

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

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

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

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

• 一步一步來！