學習TDD的心路歷程

我們聽了太多的敏捷開發,但不寫測試的敏捷,就像不會動手術的外科醫生一樣荒謬。

我在2017年上了Daniel的CSM(Certificate Scrum Master)課,上完有種毀三觀的震撼,那門課表面上在講SCRUM,其實講的是一套敏捷的人生觀。課程最後一天的下午,Daniel談到了為什麼要自動化測試。

Daniel畫了一張圖,給了一個簡單的理由:雖著時間進展,軟體的功能會線性成長,但每次Release都需要測試全部的功能。不自動化測試的話,遲早有一天你的QA會爆掉。

當時第一次接觸到Scrum,意識到這是很有價值的方法論,回去公司後迫不及待分享給同仁。但那時的我是個無知的敏捷信徒,只會嚷嚷測試很重要,但卻不會寫測試。主管聽完後,思考了一下,表示實務上有困難,PM的需求朝令夕改,如果我替軟體加上測試,軟體會變得穩定,但之後要改架構會變得困難。故決定先暫緩這樣的想法,只在幾個特定的feature上加上自動化測試,未來需求比較穩定後再來試著導入看看。

後來因為其他緣故離開了那份工作,但直到現在,我依然不認為主管當時的決定是錯的。以當時Team的狀況要導入測試的確不容易。我沒有經驗,沒辦法 show, don't tell 直接拉起袖子做,是最主要的敗因。

下一份工作我遇到軟體品質的問題,團隊對於debug相當頭痛。我開始意識到測試的重要性,於是在9月和11月,主動去上了91的極速開發TDD重構課

為了確保花的學費有價值,上課前的一個月,我決定先在工作上練習寫單元測試。我還買了Modern C++ Programming with Test-Driven Development閱讀,這是本好書,裡面用Example示範TDD的步驟,還講了許多C++的Stub/Mock技巧。但讀完後,我還是不知道怎麼在範例外的問題上使用TDD,我不知道怎麼設計Test Case、不知道怎麼選擇下一個Test Case,書上講得頭頭是道,也有很多範例程式,但是距離實踐有一大段鴻溝。

上完這兩門課後覺得非常值得,最棒的是親眼看見講師示範「好的TDD開發實踐應該是什麼樣子」。沒有榜樣自己練TDD很容易練成九陰白骨爪。親眼看見會產生疑問,此時詢問講師並獲得反饋,等於直接吸納人家的經驗值,少走很多彎路。

極速開發教的是工具,解決沒有時間寫測試的問題。而TDD重構課大概是91系列課中最有價值的一門課,實際帶你演練一次高手的TDD和重構會是什麼樣子,課程講了實例化需求、測試案例排序。其中最震撼的是,講師讓我們分組寫一段程式,並讓我們改到覺得滿意為止。隔天現場示範重構,每個步驟都拆的很細。那時才意識到,原來我以前根本不會重構,我過去一直以為的重構,就只是抽方法和取一個好名字而已。而真正的重構是有測試作為防護網、有能力辨識程式壞味、有辦法小步地穩健修改。

上課容易,內化困難

這兩門課開了眼界,脫離了「不知道自己不知道什麼」的狀態。但我其實隱約察覺,自己還有很多疑惑,但經驗還不足,說不清楚問題是什麼。

我花了兩個禮拜用Visual Studio + Resharper練習C#的Tennis Kata,解決速度的問題 。下個問題立刻接著而來,我工作用的語言是C++,但上課用C# + Java + PHP,有點尷尬。我裝了Resharper C++,但因為語言特性的關係,並不像C#版的Resharper那麼好用。理想上,重構當然不需要工具,靠Compiler應該就能實現穩健的重構,Martin Fowler的「重構,改善既有的程式設計」就有描述這些手法,但有工具會讓整件事輕鬆很多。

另外C++ Legacy Code編譯時間很長,想要替既有的程式加上單元測試不切實際。必須先Decoupling,用一些降低相依性的技巧,將修改、編譯、連結的時間降低。但這又陷入雞生蛋蛋生雞的問題,需要測試才能保證重構不出事,但髒Code不經過重構很難加測試。Code Base一旦大到一個程度,所有事情都開始變得很棘手。

我試著挑了一個獨立的套件,用C++的Google Test做TDD,替程式加入簡單的新功能。還找同事一起Pair Programming了一個下午,順便帶一些TDD的觀念。同事覺得很穩健,但是開發速度太慢,其中的Dependency Injection技巧他也不夠熟悉,要應用在團隊中太難。

儘管已花很多時間學習,但在C++開發上還遠遠不夠。一方面語言本身坑很多。另外我還需要學Decoupling技巧降低編譯時間,這需要閱讀大型C++軟體開發。如果用火候來比喻我當時的TDD技能,大概還跟火柴一樣,除了上課的範例外,給一個稍微複雜的題目就會無從下手。而網路上針對C++的TDD範例並不多,相對其他語言學習更為坎坷。

我花了一點時間學習C++的重構技巧,閱讀Working Effectively With Legacy Code。後來因為其他因素離職,時間充裕了起來。我決定把C++先放一邊,改用我還不太熟悉、但資源較為豐富的C#練習TDD。

因為平常習慣使用Linux的關係,決定要學C#實在有點糾結。C#最主要的應用場景是Windows程式和ASP.NET。在Linux寫C#就像是去日本買大同電鍋一樣。不是做不到,但是這麼做的人還不太多。我裝了跨平台的C# IDE Rider,接著花了一個禮拜練習Tennis Kata並調整開發環境。一開始頗為忐忑,因為沒有範例影片可以模仿,有點擔心會出現一些難以處理的問題,但是觀念是通的,處理掉快捷鍵相衝,刻意練習一陣子後就成功換到Rider上了。

由於Tennis Kata已經練到爛了,我在網路上找了幾個不同的Kata題目練習。先從最簡單的羅馬數字轉換器開始,知道需求後,試著自己想Test Case、排序,接著試著寫。完全不意外,思考流程非常卡。我覺得我想的演算法不夠漂亮,但又還沒想到什麼更好的作法。硬著頭皮完成後,我參考youtube其他網友的練習,試著重構,並發現很多疑問,TDD有一些優點,但也有一些TDD幫不太上忙的地方。

後來我參加了91辦的第一屆Coding Dojo(代碼道場),這是個大家犧牲能夠睡到自然醒的假日,歡樂練習TDD的社群活動。30個人輪流上台接著用TDD寫Poker Hand Kata,非常有趣。在台下抱怨人家的Code怎麼寫的那麼爛,結果上台腦袋自動一片空白。活動結束後,我和紘銘抽了兩天用TeamViewer做Online Pair Programming by TDD,練習同一道題目。合計花了約略20個小時。練習過程中,想通了很多觀念,也連帶冒出許多更進階的問題。

  • Test Case是不可能精確、完整的描述需求的。舉例而言,Tennis Kata的比分可以有無限多種,但我們不可能列出所有的比分作為Test Case。
  • 理想上,每多加一個case,只要多寫一個判斷就行。因為任何程式都是由if/for等基本結構所構成的。但要把任何問題都拆解成test case,並且每加一個test case只多一個判斷,有點太過天真。
  • 寫一個我推測很可能會通過的Test-Case,寫了就過了,是不是就破壞了紅燈、綠燈、重構的原則?
  • 辛辛苦苦花了許多時間,列出完整不同需求情境的Test Case,但列的太細,寫到一半發現許多太細的test case都沒用了,結果產生了浪費。
  • TDD似乎有種命定論的味道,一開始想的演算法如果不漂亮,那實做出來的程式也不會太簡潔。TDD有辦法協助演算法設計嗎?
  • 如果一個獨立的Test Case太大,需要幾個method才能完成,那是否要將這些method暴露成public方法?理想上是不要,所有的public method測試應該就要涵蓋到private method的行為。可是一個物件的private method較為複雜的時候,很難透過public method的測試小步小步的開發private method。
  • ......

有些偏向觀念上的問題,我就丟到課後群組裡詢問。有些問題因為自己還沒有切膚之痛,問了沒太大意義,就先放在心上,等到經驗多一點時,自然就有了自己的見解。

後來,我又練習了MineSweeper、練習了Game of Life,找另一個朋友pair了programming Bowling。這些都是網路上找得到的範例題目,但這些Kata還是讓我很不踏實,我常常會覺得自己寫得不如網友的練習影片。我甚至不確定我能不能用TDD開發一個非範例的程式。

後來過年,神來也麻將出現在每個youtuber頻道的置入,我下載了麻將遊戲來玩,把一開始給的遊戲幣都輸光後。我想到可以練習用TDD寫一個判斷聽牌的程式。如果我能把這題用TDD寫出來,就代表我已經算是踏入TDD的世界了。

我從頭開始分析需求、結果才剛開始我就放棄了,太多決定讓我思考癱瘓,我不確定我的作法符合TDD的原則、我的方法似乎不該回傳List of Reference,這絕對是有問題的。我發現我對C#還不夠熟悉。

我意識到需要對C#有更深的掌握。於是查了C#的相等性和比較、看Collection和Enumerable、看看C#是怎麼定義介面的功能。掌握這些知識後,我意識到更進階的問題:我對好的物件導向設計不夠有Sense。物件導向的六大原則我們都會背,封裝多型繼承誰不知道?但真正的問題是,平常根本沒有人告訴我們這是好的設計、這是不好的設計,大家都是悶著頭寫程式,寫完能動就算了,這樣要怎麼進步?

運氣非常好,我發現一個很棒的blog,有位外國人在Udemy開了一門線上課叫做Emergent Design。我看了幾部預告後,就決定花錢買這門線上課,花了好幾天反覆的看。裡頭用一個開發數字計算遊戲的案例程闡述設計的原則。他沒有使用TDD,並把開發過程稱為Iterative Development,我一看就就知道他的觀念和TDD是相通的,更重要的是,他補足了我在TDD學習之路上還沒被填起來最大的那個坑,設計。

Emergent Design做兩件事,一個是小步開發(Develop Iteratively),另一個是持續設計(Design Iteratively)。每一次開發,永遠只處理當前最直接的問題,並把更小的問題委託給另一個物件解決。影片中大量使用了LINQ,並且闡述了Lazy Evaluation的潛在問題,我發現我只會幾個基本的LINQ的語法,常常需要把影片暫停,去查語法,再繼續看下去。我才意識到,原來LINQ是C#的精華。於是我又花了一段時間,整理並練習了LINQ的所有API,至少要讓自己在遇到問題時,知道手邊有這個工具可以用。

我把影片反覆看了好幾次,不懂的地方就暫停。裡頭提到許多相當實務的設計思維,像是把Domain Code與Common Code分離,不僅僅是為了Code Reuse,更大的好處是你需要理解的Code Size會變少。儘管他沒有用TDD,但是依然遵守著類似TDD的原則,在不破壞程式先前的功能下加入新功能。抽象應該是自然而然演化出來的,而不是直接一開始寫死的。如果不這麼做,你必須腦袋時時刻刻保持著你幻想的抽象概念,寫Code時還要驗證該抽象是否合理,很容易會造成自證預言式的設計。

我們很常用蓋房子來比喻軟體的設計。把規格拆成一個步驟一個步驟做,先打地基、架鋼筋、之後接著灌漿,如果我要求你改變房子的設計,修改就會變得很棘手。好的設計應該像是用樂高積木一樣,當需要修改時,只要抽換掉要修改的積木就可以了。

我從線上課程中收穫良多,終於,我覺得自己已經知道大部分的工具。開始試著用TDD寫判斷麻將聽牌的程式。這次比之前都順利,我開始能夠判斷作法的好壞,儘管不到流暢,但終於能夠完成整個練習。我開始體會TDD的美麗之處。TDD的本質不是單元測試,而是強迫開發者及早面對「設計」的問題。透過重構、決定哪些方法要放在同一個類別,實現bottom-up的設計,透過emergent desgin和測試,預先思考一個類別的職責,實現top-down的設計。提早思考函式介面的設計、分離意圖和實做的差異。當整個程式開發的每一步都照著TDD原則走,等於每次寫程式都像打一套詠春。練習久了,把心法和招式內化,日後出手自然就知不同。

剛上完91的課時一直不敢寫心得文,課程本身很棒,指出了學習的正確路標,但內化技能需要時間、練習及填坑,把頭洗下去說出的話比較有說服力。路還很長,先把這段心路歷程做個記錄,希望能幫助想入門的朋友少走一些彎路。另外有哪間公司或團隊有在工作上使用TDD或寫單元測試的,拜託留言或私訊讓我知道,我準備開始找工作啦!

2
Leave a Reply

avatar
2 Comment threads
0 Thread replies
0 Followers
 
Most reacted comment
Hottest comment thread
2 Comment authors
Hans Chengary Recent comment authors
  Subscribe  
newest oldest most voted
Notify of
gary
Guest
gary

覺得有幫助。
知道 TDD 的概念後覺得很棒,但是面對目前公司所有用 C 語言開發的所有東西,大家都不敢改以前的 code ,也沒有自動化測試。想自己用 TDD 卻一點也用不出來。
大大的文好像有個明燈告訴我那裡有路

Hans Chen
Guest
Hans Chen

大同電鍋真的是很有趣的比諭. 我們團隊有在寫單元測試並連接到整個 CI 系統, 主要語言也是C++. 目前正在思考要如何導入TDD, 剛好看到你這篇文章獲益良多. 如果有興趣的話歡迎和我連絡哦. 謝謝