副標題:崇尚簡約之道的測試驅動開發,除了讓軟體人員為自己寫的程式負責外,還能提昇勇氣,勇於溝通與更多的回饋。
Test Driven Development By Examples ———————————– 作者/Kent Beck /著 出版社/Addison-Wesley Professional 出版 ISBN/ 0321146530 |
內容簡介
Clean code that works–now. This is the seeming contradiction that lies behind much of the pain of programming. Test-driven development replies to this contradiction with a paradox–test the program before you write it.A new idea? Not at all. Since the dawn of computing, programmers have been specifying the inputs and outputs before programming precisely. Test-driven development takes this age-old idea, mixes it with modern languages and programming environments, and cooks up a tasty stew guaranteed to satisfy your appetite for clean code that works–now.
Developers face complex programming challenges every day, yet they are not always readily prepared to determine the best solution. More often than not, such difficult projects generate a great deal of stress and bad code. To garner the strength and courage needed to surmount seemingly Herculean tasks, programmers should look to test-driven development (TDD), a proven set of techniques that encourage simple designs and test suites that inspire confidence.
By driving development with automated tests and then eliminating duplication, any developer can write reliable, bug-free code no matter what its level of complexity. Moreover, TDD encourages programmers to learn quickly, communicate more clearly, and seek out constructive feedback.
Readers will learn to:
- Solve complicated tasks, beginning with the simple and proceeding to the more complex.
- Write automated tests before coding.
- Grow a design organically by refactoring to add design decisions one at a time.
- Create tests for more complicated logic, including reflection and exceptions.
- Use patterns to decide what tests to write.
- Create tests using xUnit, the architecture at the heart of many programmer-oriented testing tools.
This book follows two TDD projects from start to finish, illustrating techniques programmers can use to easily and dramatically increase the quality of their work. The examples are followed by references to the featured TDD patterns and refactorings. With its emphasis on agile methods and fast development strategies, Test-Driven Development is sure to inspire readers to embrace these under-utilized but powerful techniques.
前言
我一位軟體設計的夥伴,是我在這個業界看過上千軟體人員以來,唯一我認為是最為天才的。不是只有 IT 技術的學習能力快速而已,他更具備的是柔軟的頭腦與身段,抽象能力極高,擅長把軟體作軟,令人讚嘆與嘆為觀止。但是我還是覺得他與國外軟體先驅的大師們仍有一段差距,並非是實作,也不是學習的能力之差,最最主要的差距就在於:創新能力! 當然,我與他非常熟,才敢這樣說,而他也能認同此點。我更期勉如此有天分的人能往更高段的軟體設計殿堂,使得有能力的人可以有更多的貢獻,幫助更多人。
什麼叫做創新能力? 舉個例子,我輩之流如我是可以看得出早期 EJB 規格的問題點(簡單的說,軟體結構被該規格綁得死死的),所以會批判與避免使用它。但是 Rod Johnson 卻不是只有批判反對而已,而且還身體力行,寫出了 Spring Framework,實現 IoC (Inversion of Control), AOP (Aspect-Oriented Programming) 的輕量級開發框架,真正釐清 Developer 與 系統層級服務的責任; 再如本次書評要介紹的: Kent Beck 因為在輔導專案的過程中,深深感於測試應伴隨著所開發的程式碼,而不是延遲 (太多大型單位都把測試當作一個重要的製程,卻是交給另外的部門,在開發後才展開測試,這樣能應變測得好? 我很懷疑),所以主張“測試先行 (Test First)”。而為了實現與主張他的理念,甚至設計出 免費開放的 JUnit Framework 等測試框架,以及寫出如本書“TDD (Test Driven Development by Example)”,造福諸位大德。我輩之流雖無法創建如此了不起的框架,但起碼也要作一些推廣,讓 Developer 們瞭解什麼才真正是維繫軟體品質的重要關鍵。
測試先行!先行測試!
我實在是太欣賞 Kent Beck 的寫作風格了。本書才 200 頁初頭,卻共分為 32 個章節。怎麼會這麼多章節? 原來作者根本沒有分小節,然後就是完全以例子,每一章只完成一個小目標、解決一個小問題就結束了。全平面的寫法,沒有艱澀難懂的術語,簡約的風格,真正夠得上是“俗又有力”!
全書共分為三大部分,前兩大部分就是範例,第三部分則是 TDD 的設計模式(Patterns)。第一部份以一個“幣值轉換”的程式範例(本書開頭的介紹中特別有說明到該實際案例的緣由),利用 Java 程式碼範例,來逐漸揭露出 TDD 的設計意涵。這個範例,你初一眼看到時,會覺得怎麼有那麼白癡的寫法? 是的,Kent Beck 盡量模仿初學者剛寫程式碼的程度,這也同時說明了 TDD 是多麼的簡單明瞭,初學者一學就會,也懂得如何慢慢來修正自己的程式碼 (這其實已經逐漸走向設計之道了)。這一部份會讓你瞭解到什麼才叫做是“Test First”? 還沒寫類別程式碼之前就先寫測試程式碼了! 相當之令人驚訝。當然,測試一定不會過,再來才是開始寫你的主題程式,新增類別、編輯屬性、修改參數 …等,請記得,每次只修改一個地方,然後測試它,逐漸讓錯誤減至零,測試亮綠燈為止 (測試有錯會亮紅燈)。簡單的設計、列出工作清單、一次只解決一個問題、測試它、讓它正確,反覆修正... 正是 TDD 最重要的精神。
第二部份則是藉由 Python 語法來探索 xUnit 測試框架的設計過程。是的,這一部份真的是在教你如何撰寫所屬自己的測試框架,本以為開發 Framework 是相當困難且嚴謹的設計工作,但你看 Kent beck 又是近乎白癡的作法,但竟然三兩下就可以開發出測試框架,而且在設計的過程中,還仍能秉持著“測試先行”,真是神奇! 會使用 Python 作為範例的原因,我猜想除了語法易懂之外,它本身是屬於“script-based”的語言,藉此來證明這樣也是能實現測試框架的實作。事實上,目前已知有 30 餘種程式語言支援 xUnit Framework,那麼為何作者還要鼓勵程式人員開發所屬自己的測試框架呢? 兩個理由:1.讓你有對測試工具自我主宰的感覺;2. 藉以探索測試內部的機制。
第三部分是 TDD 的設計模式。這裡談及到了測試的策略思考,包括到底測試的意涵為何、那個時候測試、如何選擇什麼樣的邏輯與資料來作測試。如何測試? 不要紙上談兵,只寫那些測試案例,就是一定要寫自動化 (automated)的測試程式;那個時候測試? 無庸置疑,測試先行! 甚至主題程式還沒有寫出來、資料也還沒備妥之前;測試什麼? 功能性 (針對需求)與單元性(Unit)的測試 (針對本質性的領域類別)。 TDD 崇尚簡潔 (Simplicity),擺脫那些無謂的高度儀式化吧,從簡單的地方開始做起,為自己所寫的程式負責任,維繫最基本的程式品質,並期能持續演化而又不影響既有功能正確性的前提下。
Simplicity is the Power!
TDD 只有一個核心精髓與兩個原則。精髓為:讓程式碼可以運行並能保持純潔無暇 (Clean code that works)。而原則是:1. 只有自動化測試失敗時,才寫新的程式碼;2. 消除重覆 (duplication)。尤以後者,又與系統架構中的相依性 (dependency)設計有相當密切的關係,當消除掉重覆的程式碼後,往往系統的耦合 (coupling)程度降低,也使得可再利用性的價值提昇。
Kent Beck 還特別在序文中提及了“勇氣 (Courage)”,把 TDD 與之關連一起。他認為測試驅動是一種可以在開發過程中控制憂慮感的開發方法,它可以讓你:盡快具體的學習,而不是一直處於試驗性的階段;取代沈默寡言,讓溝通更多的交流;不是躲開回報,而是更能尋求具體有幫助的回饋 (feedback)。當讀者閱讀完本書後,應該就能準備:1. 從簡單開始做起;2. 寫自動化的測試程式;3. 重構 (refactor),每次只增加一個新的設計。
Hi Patrick:
有緣若您回台灣可以見面聊聊 🙂
面談 is hard. I am based in Sydney.
You are mostly welcome to contact me if you happen to be on business trip to Sydney.
Hello Partrick:
UAT 我倒是知道。 ^^
SIT 我也常需要作測試的;BAT 這是業界常碰到的 “痛” 🙂
此三者,我倒是蠻清楚如何作測試的,以文字說不清楚,歡迎面談。 ^^
Sorry Kenming,
SIT –> System Integration Test
UAT–> User Acceptance Test
BAT –> Business Acceptance Test
Hi Patrick:
我不曉得什麼是 SIT, UAT, BAT 這些專有名詞耶 !^^
倒是那本 “Object Model”, 11期書評所介紹論及 Transaction Pattern, 我真的是強烈建議您買來參考喔。 試著從結構的角度,而不僅此於需求的角度來看系統。 🙂
Hi 唯一的天才:
應該可能您說得對吧! 我也只是在台灣與網路與多位軟體職者打過交道,(我相信還有諸多臥龍藏虎的能人,只是我沒機會看到的),所以我這應該也算是井底蛙吧。 !^^
不過還是說明一下,這是我的 “主觀意見”,也只僅此於我現在的看法,與他人是無關的。
我是以為,我那位朋友是有 “第二流中的第一流” 的層級,在內容中我也提及,我更為欽佩的是那種具有在軟體上的創新能力與具體實現能力。包括 Kent-beck, Martin Fowler, Jaconson, 四人幫, …等軟體界的大師。那真的是難望其備的。
我一直以為在歐美(尤其美國),這種第一流的天才真的不少,昨天我還在與朋友們討論這個議題。我在想,現實上的大環境應該是與天才的造就有關係吧。
Hi 樹頭咕咕鳥:
別只在巴斯通死守著啦,我們準備要大反擊了耶!
Hi Kenming, Can you recommend some of English to Chinese translated books for SIT, UAT or BAT ? I read through the Explore for Requirement that you recommended, it was really great.
上面的訪客似乎沒看清楚kenming的文章敘述:XD
也許您朋友是個天才,
但說他是唯一的天才,
聽起來好像…….
井底之蛙的口吻~~
可能很多台大電機或是Google的員工就不見得這麼認為。
我看過的天才就很多,
有許多人是自己感覺一輩子無法望其項背的(並非我太笨^^)。
哇哈哈
不嫌棄的話
有機會再找老哥聊聊
最近玩 game 玩到爆
(老弟我也敗了一張 7900 GTX )
————————————————————
疾如風 徐如林 侵略如火 不動如山
原來是 樹頭孤鳥 先生。 ^^
是否跑去深山修行了,竟然如此之久不見蹤影~
是的
本書讓我們 更能給他 感受到 agile development 的 “節奏”
————————————————
其疾如風 其徐如林 侵略如火 不動如山