2014年6月6日 星期五

好書分享:Test-Driven Development by Example

TDD by Example 是大師 Kent Beck 於 2002 年出版的書
TDD 及其衍生的開發方法對近十年的軟體開發有著巨大的影響


前言

出來工作後偶爾都會聽到技術人提到「TDD」或是「*DD」等等關鍵字
一兩年前便取得本書,有時候睡前會閱讀此書
卻因為常常看到睡著導致每次看都要重看 Orz
最後就把本書束之高閣

趁著前陣子 TDD 大戰 上個月便一口氣把本書看完
並且撰寫此文,讓對本書有興趣的朋友能夠評估是否需要閱讀


如何取得此書?

iBooks / Amazon 皆可取得原文電子書
對岸似乎有中譯本 ...

另外由於加拿大約克大學在 2004 年有開過一門「Software Design
官網內恰巧有提供本書的第一章當作參考資料 點此下載

點選左手邊的 Resources 分頁,可以看到參考資料還有 Design Pattern ...
這大概就是「城鄉差距」... (看看台灣的課程 ... BJ4 ... Orz)


誰適合閱讀此書?

TDD 的概念可以說是在 2002 附近才被 Kent Beck 正式提出(不是發明)
事實上此技術已在 199x 年就被少數人採用並且逐步發展
提出後的這十多年間,該概念被不斷再解釋、延伸、補強 ...

若要學習 TDD ,本書已經不是唯一的途徑(有前輩帶 + 自己動腦動手最快)
但本書有以下優點:

  • 不會太大本,好讀
  • 舉例的內容著重在概念上,好理解
  • 是最早花這麼多篇幅討論 TDD 的著作,閱讀後能協助理解後來的延伸
  • TDD 的概念在此時已經算是成熟而完整

本書適合給「想要了解 TDD 發展」、「英文閱讀能力中等」的朋友閱讀
(像我只有中下,一直查單字讀得有點 zzZZ)


而您若是想要學習 TDD
本書的角色是幫您在概念上醍醐灌頂
然而若要順暢實作,則有賴於動手動腦以及閱讀更多著作


此書內容在說些什麼?

本書分為三大章節:

  • The money example
  • The xUnit Example
  • Patterns for Test-Driven Development

藉由第一個章節「The money example」導入貨幣的範例
作者將 TDD 的基本流程跟執行時的思路告訴讀者
這邊的範例程式碼使用 java ,且實作的步驟非常小而略瑣碎
(這可能是我之前一直看到睡著的原因 ...)

第二個章節「The xUnit Example」頗為有趣
作者示範如何以 TDD 的方式開發 Testing Framework
範例程式碼皆由 Python 實作
此範例我個人覺得比第一章節的範例有趣且實用許多

第三個章節共有以下子主題:

  • TDD patterns
  • Red Bar patterns
  • Testing patterns
  • Green Bar patterns
  • xUnit Patterns
  • Design Patterns
  • Refactoring
  • Mastering TDD

簡言之,作者探討在執行 TDD 各個過程可能會遇到的情境與決策方式
由於 TDD 是由許多程序組合而成的開發方式
無可避免地會討論到 Design Patterns 與 Refactoring 等等技巧(都是點到為止)


部分摘要

TDD is an awareness of the gap between decision and feedback during programming, and techniques to control that gap. "What if I do a paper design for a week, then test-drive the code? Is that TDD?" Sure, it's TDD.


TDD is not about taking teeny-tiny steps, it's about being able to take teeny-tiny steps.


If you can make steps too small, you can certainly make steps the right size. If you only take larger steps, you'll never know if smaller steps are appropriate.


Rather than apply minutes of suspect reasoning, we can just ask the computer by making the change and running the tests.


TDD makes this work well by giving you running concrete examples from which to generalize, instead of having to generalize purely with reasoning.


Exploration— When I'm faced with a new programming language, I implement xUnit. By the time I have the first eight to ten tests running, I have explored many of the facilities I will be using in daily programming.


One convenient implication of isolated tests is that the tests are order independent.


A second implication of isolated tests is that you have to work, sometimes work hard, to break your problem into little orthogonal dimensions, so setting up the environment for each test is easy and quick.


What should you test? Before you begin, write a list of all the tests you know you will have to write. The first part of our approach to dealing with programming stress is never to take a step forward unless we know where our foot is going to land.


TDD is a refinement of the Ungar Shower Methodology. If you know what to type, type the Obvious Implementation. If you don't know what to type, then Fake It. If the right design still isn't clear, then Triangulate. If you still don't know what to type, then you can take that shower.


What don't you have to test?
The simple answer, supplied by Phlip is, "Write tests until fear is transformed into boredom."


I learned exactly the opposite from books: "Code for today, design for tomorrow." TDD appears to stand this advice on its head: "Code for tomorrow, design for today." Here's what happens in practice.


Good engineering is maybe 20 percent of a project's success. Bad engineering will certainly sink projects, but modest engineering can enable project success as long as the other 80 percent lines up right. From this perspective, TDD is overkill. It lets you write code with far fewer defects and a much cleaner design than is common in the industry.


Robert Martin and I did some research into this style of TDD. The problem is that the design keeps surprising you. Perfectly sensible design ideas turn out to be wrong. Better just to think about what you want the system to do, and let the design sort itself out later.



心得

初閱本書第一章時,「Test First」的做法讓我想通了不少事情
包括重新重視每個 unit 的使用情境以及意識到小粒度 testing 的重要性
進而放大粒度,從大組件的功能性 => 系統的功能性 => 產品的功能性 ...
來思考「Test First」的可行性

廣義 Test First 的背後觀念其實是「使用情境的提前模擬」與「驗證方式的提前確定」
做事情前,本來不就應該訂定目標跟檢核辦法嗎?

TDD 節奏的概念很簡單,大多數工程師都能夠在幾分鐘內了解
看過本書的開頭內容後,我也一直以為我大概知道 TDD 是怎麼一回事
但是這是不對的,我就跟看完 TDD 流程圖就覺得已經了解  TDD 的人一樣
只是看到冰山一角而已 ... Orz

TDD 是與 Design Patterns, Refactoring, xUnit, XP/Agile, Mocking ...
等等觀念、技術、開發方法「同綑」在一起的
一直到前陣子一口氣看完本書,並且買了很多雞排觀看 TDD 大戰
我才意識到這件事

我想,閱讀本書最大的好處
大概就是能回到 2002 以前,去看看這門技術是怎麼一回事吧!



隔一陣子來嘗試撰文整理 TDD 大戰懶人包
TDD is Dead V & VI 的最終場 hangout 大戰都已結束
應該算是戰完了吧 XD





沒有留言:

張貼留言