實戰敏捷開發 Practices of an Agile Developer (3) 測試篇

上一章談了來自客戶的 Feedback，這一章作者談另一種回饋機制：透過程式測試得知目前開發的情形(Coding Feedback!)。

Put Angels on Your Shoulders (讓測試當你的天使)

Code 一直在變，我們需要一種持續又快速的 feedback 告訴我們這些程式碼建不健康：是我想要的程式嗎? 最後的 commit 有沒有弄壞任何東西? 這時你需要的一種機制可以一直幫你確保這些，也就是自動化的單元測試(unit tests)。

因為測試的流程總是 1.Setup(設定初始資料) 2.Exercise（執行某些操作) 3. Verify(驗證輸出結果與預期相同) 4.Teardown(清空資料)，所以目前每套程式語言一定都會有一套 xUnit framework 的測試框架可供使用。

另外還可以加裝一套 continuous build 工具(例如 CruiseControl)，它可以自動 checkout 最新的程式碼並測試，一旦有人送交了有錯的程式碼，馬上就可以通知並修正(這時候fix bug最簡單且成本最低)。

當你的 unit tests 達到 Regression tests 程度時，這時候做重構(refactoring)時就有更大的自由(自信)，因為不需要擔心改爛了什麼你不知道的東西。

另外搭配 test coverage 工具可以幫助你有個大概的鳥瞰。寫 test 像是一個聰明的投資，因此報酬效率也很重要，trivial method 不需要寫，把火力放在你最擔心出錯的地方。

Use It Before You Build It (用之前先測試怎麼用)

這節進一步談測試驅動開發(TDD)，在寫程式前先寫好測試程式。透過先寫測試程式，可以從使用API的觀點來思考怎麼寫程式、怎麼設計API，因而寫出更好用、一致及簡潔的程式介面。

Different Makes a Difference (差一點差很多)

在我這台沒問題啊，為什麼換一台電腦就不對了? 只要換一個平台(即使是不同版本的作業系統)，不同就是不同，而太晚發現這樣的問題要修理是非常麻煩的，尤其是正要 release 的時候才發現它沒辦法在某某你想要的平台上執行。

我們當然可以要求 QA team 要在不同平台上測試，但是如果他們只是手動測試，就不如自動測試來的及早發現。我們已經會在 commit 程式前在自己電腦上執行一次 unit testing，現在要做的事情是要在你所要支援的不同平台、不同版本上再測試一次。不過好累啊，這時候就必須靠 continuous integration 工具來幫忙，每當有人 commit 時，這個工具就會自動 checkout 出來執行測試，我們分別在不同平台(例如可以使用 VMware 或 Virtual PC)上設定好這個工具來做自動化測試。

Automate Acceptance Testing (自動化驗收測試)

重要的商業邏輯除了 unit testing，還需要驗收測試獨立於所有程式之外，而且客戶必須親自驗證這個結果。也因為因此，我們需要一個工具讓客戶也可以新增編輯跟修改驗收測試(without coding)，

這本書介紹的工具是 fit.c2.com/，它使用 HTML table 當作定義的介面，客戶可以直接編輯加入新的功能，接著加入可能的輸入與正確的預期值。然後 developer 再根據這個 table 產生 fixtures 資料，並比對測試結果是否成功。

感覺像是協力式的 unit testing，你還是必須自己寫測試，只是必須有別人提供你什麼是正確答案。

Measure Real Progress (測量真正的進度)

紀錄花了多久做事提供了很好的 feedback，可以幫助專案計畫、估計跟效率測量。但是一般常用的 timesheet 多半用於薪水用途而非真正花費的時間，這點要特別注意。另外常用的紀錄完成百分比，作者也認為很沒用。一個比較好的方式是紀錄 1.估計多少時間 2.已經花了多少時間 3.估計還需要多少時間來完成。根據真正花了多少時間的經驗，加以比對一開始的估計值，可以獲得很好的經驗用於估計下一個類似的任務。

紀錄真正的時數對於使用 backlog(要完成的任務清單)和 Iteration 也非常重要，如果剩餘的時間超過這次 Iteration 了，就知道必須移動某些任務到下一個 Iteration，反之則有時間多加工作。

最後是注意紀錄的時間單位，以分鐘太細了，以週就太粗囉。我們的經驗是超過一天的 Ticket(Issue) 應該都可以想辦法拆小，1hr、2hr、4hr、8hr 應該是不錯的範圍。

Listen to Users (聆聽使用者)

作者在這章最後特別提了使用者的回饋。即使有寫測試程式，我們還是很容易忽略來自真正使用者的聲音。每一個使用者的抱怨都有其道理，盡量試著找出真正的問題，而不是怪罪使用者不懂、不了解系統如何操作。
程式Bug、文件Bug、使用者會認知錯誤也要算是Bug。而不是讓客服人員回答說：喔，那不是Bug, 你犯了一個大家都會犯的錯誤。即使聽起來很笨，也應該去試著聆聽。