測試驅動開發(TDD)

為什麼要把TDD的學習放在介於Java 基礎與學習OOP之間呢 ?
Image of Agile Java(TM)
一位不了解TDD精神及實際融入工作的Java人, 不能稱為一位“開發者", 但您可能成為一位很高效率的 Code 工人, 充滿無效率甚至低品質的驗證, 也淡忘了當初學習追求卓越的精神.




TDD簡介


根據 Wikipedia 的說明: 測試驅動開發的比喻。
開發可以從兩個方面去看待:實現的功能和質量。
測試驅動開發更像兩頂帽子思考法的開發方式,先戴上實現功能的帽子,在測試的輔助下,快速實現正確的功能;再戴上重構的帽子,在測試的保護下,通過去除冗餘和重複的代碼,提高代碼重用性,實現對質量的改進。可見測試在測試驅動開發中確實屬於核心地位,貫穿了開發的始終。


反向思考


  • 單元測試不會幫助你寫出更好的代碼
    • 單元測試的主要目的是,為了防止你不會因為一個改動而引入Bug,但這並不會讓你能寫出更好的代碼。這只會讓你寫出不會出錯的代碼。同第一點,這樣的方法,只不過是防止糟糕的程序員,而並不是讓程序員或代碼質量更有長進。反而,程序員通常會借用“單元測試”來為自己代碼做辯解,而此時,單元測試報告成了一種託辭。




JUnit



Eclipse - JDT & JUnit


好文選


  • J.B. Rainsberger:「整合測試是個陰謀」- 2009-05-05
    • 他繼續向讀者演示了一個相對較嚴格的基於數學的檢驗,察看針對一個中型大小Web應用程序進行集成測試所要花費的代價。通過給出這些數字(「至少10000(個測試),甚至無數多」),J.B.描述了這些測試佔用了大量的項目時間,且很多團隊最終會對此種做法產生抗拒。
    • 在我編寫某個(支持TDD測試的對象的)測試時,我很清楚我的目標,並專注於讓其通過測試,隨後關注如何將該對象良好地集成到系統中。這項工作存在著多次 迭代,需要持續的注意力。這種關注和檢查的一次次循環構造出了一種獨特的節奏,並成為了開發人員保持注意力的動力。這也就是經常提及的所謂的「流」。6秒 鐘的測試很容易組成這個良好的循環,而1分鐘的測試則會打破開發人員工作的進程。
  • 測試驅動開發面臨的挑戰
  • 單元測試的七種境界


References(參考)







Comments