最終目標是整潔可用的代碼

?

我們不是從建立對象開始，而是從測試開始

?

了解需求-》設計測試 -》讓測試通過

?

列出所有已知問題，然后一個一個解決；

?

培養將軟件開發化為一小步一小步開發任務的能力

?

測試程序與代碼所存在的問題不在于重復設計，而在于代碼和測試程序之間的依賴關系

?

如何開始設計測試代碼，通過方便測試的角度來修正程序的設計，如果兩個方法之間有依賴關系怎么處理，

?

先寫最簡單的測試，只根據需求，然后發現實現有問題，修改測試，修改代碼（or修改代碼 修改測試）？

?

?

讓測試迅速通過的方法：

?

偽實現，顯明實現；

?

將一個設計缺陷（副作用）轉化為一個由此缺陷導致運行失敗的測試程序；

用偽實現使代碼迅速編譯通過；

輸入正確的代碼使測試盡快工作；

?

寫一個測試程序；

讓測試編譯通過

測試程序運行失敗

讓測試程序可以運行

消除重復設計，優化設計結構；

?

Test DB：

?

1。 是否可以連接到數據庫；

2。是否有權限執行存儲過程；

?

?

DBTest test = new DBTest(connectstr);

MyTest mt = new mt(connectstr);

IsEquel(test.CanConnect(), mt.canconnect);

IsEquel(test.CanExe(sql), mt.CanExe(sql));

?

TDD的應用粒度：我覺得一個軟件還是需要現有一個整體的設計，對于具體非常小的模塊可以基于TDD來開發

光設計或做原型是不是比TDD更加清晰一點呢？TDD的似乎是摸著石頭過河，高屋建瓴豈不是更好？

我覺得TDD最大的優點是從使用的角度而不是開發的角度來看待軟件；能夠生成更好的應用接口。

單元測試與Scrum：單元測試的優點是隨著測試用例的累積，對于系統的修改有更多的質量保證，但是隨著測試用例的增加，維護成本也是不斷提升，特別是在scrum模型中，單元測試似乎很雞肋了

?

安排，行動，斷言

?

若在幾個測試中用相似的對象，我們將一次創建所有對象來測試，但同時盡量避免測試用例之間的耦合

?

斷言優先

?

什么時候寫測試，在哪里寫測試，什么時候停止寫測試：

從計劃列表里選擇具有指導意義而且你有把握實現的測試；

從測試某個實質上不做任何工作的操作開始；

?

轉載于:https://www.cnblogs.com/end/archive/2010/12/05/1896732.html

總結

以上是生活随笔為你收集整理的《测试驱动开发》读书笔记的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。