最近在學習測試驅動開發（testdriven development，簡稱tdd）。我的感受可以用這句來形容比較貼切，「理想總是飽滿的，現實都是骨感的」。
當我說「理想總是飽滿的」時，那是因為tdd所致力於的目標所帶來的好處，確實很誘人。**松耦合、不懼**重構等等，這些都是極具價值的。
當我說「現實都是骨感的」時，那是因為想用tdd去開發專案，需要了解的東西確實比較多，不然你會發現實踐tdd很難很難！怎樣讓**具有可測試性，怎樣處理依賴，怎樣建立好的單元測試等等，這些都是要深入了解的。
以下是一些個人覺得一些很重要的知識點，僅供參考。每乙個知識點都值得我們好好深究。我們的終極目標是理想和現代都應該是飽滿的。
solid
uncle bob著名的五大原則總結得非常好。你可能覺得很好理解，但付諸實踐好像不是那麼簡單。當你真正能得心應手地付諸實踐時，你會發現solid能極大地改善我們的**。尤其是dip，對tdd來說，很重要很重要。如果不能實現依賴隔離，我們就無法把測試僅僅侷限在一小段**內，於是那些沒有隔離的依賴**也會影響單元測試！
first
這是寫單元測試時，應該謹記的五大原則。
依賴注入（dependencyinjection）
單獨拿出來說，那是因為太重要了。我們寫**的時候要特別注意依賴，我們常用依賴注入來建立接縫（seam），這樣在單元測試的時候才能模擬各種依賴。
moq / automoq
第三方庫，利用他們可以輕易實現各種依賴的模擬。
ninject、autofac等
第三方庫，這些能幫助我們自動地建立程式需要的物件樹。
mvvm
程式高層架構應該實現分層。只用讓ui層和業務邏輯層（business logic）分成，我們才能測試業務邏輯層。mvvm是乙個非常好的架構，如果你開發基於xaml的程式，mvvm一定要掌握！
prism、mvvm light toolkit等
第三方庫，這些是幫我們更快實現mvvm的輔助庫。非常好用。
我的近期目標是也能寫出好的能測試業務邏輯層的單元測試。我覺得業務邏輯層的單元測試比較難，只有很好的掌握了好多知識以後，才能寫出很好的業務邏輯層的單元測試。加油！
TDD 測試驅動開發
test driven development 測試驅動開發是敏捷開發中的一項核心實踐和技術，也是一種設計方 tdd的原理是在開發功能 之前，先編寫單元測試用例 測試 確定需要編 寫什麼產品 tdd雖是敏捷方法的核心實踐，但不只適用於xp extreme programming 同樣可以適用於其他開...
測試驅動開發TDD
測試驅動開發 testdriven development,tdd 的基本思路是通過測試推進整個的開發工作，並不只是單純的測試工作。利用這種測試方法時，若要完成某個功能，某個類，首先不是編譯正式的 而是先編寫測試 考慮其如何使用 如何測試。然後在對其進行設計 正式編碼。t dd具有很強的目的性，是在...
tdd 測試驅動開發
這是一張影響圖 當壓力越大時，所做的測試就會越少。測試越少，犯的錯就會越多，就會感到更大的壓力。這是乙個會造成情境越來越糟的迴圈。我們用事先編寫的測試來驅動開發，因為測試先於開發，所以我們在感到壓力時，就執行這些測試，它們會馬上給我們一種系統良好的感覺，而且會減少開發出錯的次數，進而減少我們的壓力，...