【單元測試的藝術】Chap 9: 在組織中導入單元測試

目錄

• PART I: 入門
  • Chap 1: 單元測試基礎
  • Chap 2: 第一個單元測試
• PART II: 核心技術
  • Chap 3: 透過虛設常式解決依賴問題
  • Chap 4: 使用模擬物件驗證互動
  • Chap 5: 隔離（模擬）框架
  • Chap 6: 深入了解隔離框架
• PART III: 測試程式碼
  • Chap 7: 測試階層和組織
  • Chap 8: 好的單元測試的支柱
  • Chap 9: 在組織中導入單元測試
  • Chap 10: 遺留程式碼
  • Chap 11: 設計與可測試性

前言

人們不喜歡改變，改變通常伴隨大量的 FUD (Fear, Uncertainty, Doubt)。作者曾幫助過數家公司，將 TDD 和單元測試導入到組織文化中，但有些成功、有些卻失敗了，內容包括以下幾點：

• 成為導入變革的領頭羊：前置作業
• 成功之道
• 失敗原因
• 質疑和回答

一、逐步成為導入變革的領頭羊

如果你想成為組織變革的領頭羊，首先應該接受這個角色，畢竟，總是需要有人承擔起責任，確保不會因為缺乏動力而失敗，這個人就是你。

1. 準備好面對各種質疑
2. 說服組織內成員：支持者和反對者
   • 支持者：找到最有可能的支持者，通常是喜歡新技術，樂於接納改變的人，讓他們成為你的支持者，請他們幫助你回答人們的疑問，並幫助他們做好準備
   • 反對者：找到反對者，如：經理可能會反對增加單元測試，宣稱會過多地延長開發時間，增加需要維護的程式碼，建議你可以讓他們成為過程中的參與者，而不是抵制者（反之，高談闊落他們哪裡可以做得更好往往不會造成好效果）。
3. 找到可能的切入點
   • 選擇較小的團隊
   • 建立子團隊
   • 考慮專案的可行性
   • 使用程式碼和測試審查作為培訓工具

二、成功之道

一個組織或是團隊要開始改變一個流程，有兩種方式：

1. 由上而下：游擊式進行
   • 游擊式的推動者，通常厭倦墨守成規
   • 有的時候，開發人員直接採納試行這樣的變革，接著管理者也願意接受了
   • 另一種是開發人員先提出要導入這樣的變革，然後管理者也願意支持
2. 由下而上：說服高層
   • 由一個經理或開發人員來啟動這個流程
   • 或是另一個中階主管看到了別人的示範或是書籍（比如本書），從中尋找到具體改變的好處

接著，我們還可以利用一些其他方式，來增加成功機率：

• 引入外援：找專家來協助變革
  • 言論自由：顧問可以說出公司內部的人不方便說出的話
  • 經驗
  • 專職時間：顧問是專職的，公司內的員工通常有別的事情要做
• 讓進度可見
• 設定具體目標：
  • 提高測試程式覆蓋率與程式碼改動率的比例
  • 減少重複出現的 bug
  • 降低修復 bug 的平均時間（從發現到完成）
• 應對阻礙：導入變革時，阻礙在所難免，大部分來自組織內部
  • 技術性：只要能找到正確方法，技術障礙很容易解決
  • 組織性：組織上障礙需要更謹慎小心，採用心理學方法解決
  • 記得，至少堅持三個月，轉變本非容易，你必須做好壓力下堅持的心理準備。

三、失敗原因

• 缺乏驅動力
• 缺乏政策支援
• 糟糕的實現和第一印象：找有經驗的人一起參與
• 缺少團隊支持：溝通、溝通、再溝通

四、影響因素

人，以及人的行為模式，比單元測試更有趣。有關於影響力的一本書《Influencer: The Power to Change Anything》，其中有句話常被提及：「你看到的每一個行為，都有其必然發生的理由。」也就是說，除了意願和能力，還有其他因素影響人的行為。

• 個人能力
• 個人動機
• 社會能力
• 社會動機
• 組織（環境）能力：環境因素（建置、預算）
• 組織動機

五、質疑和回答

常見的問題：

1. 現有流程加入單元測試需要增加多少時間
   • 
   • 因此，你得強調：雖然單元測試增加了開發這個階段的時間，單是單元測試提升了程式碼的可維護性和品質，使得產品的交付週期得以縮短，這一點非常重要。
2. 單元測試是否會搶了 QA 飯碗：
   • 單元測試提供了對抗 bug 的第一層防線
   • QA 提供了第二層：驗收層
3. 證明單元測試確實有效的方式：
   • 建立量表
4. 單元測試有用的證據：
   • 找一些相關其他人的文章或經驗來佐證
5. QA 部門還是能夠找到 Bug 的原因：
   • 整合測試能夠發現單元測試發現不到的問題
6. 我們有大量未經測試的程式碼，應該從哪裡開始
   • 通常，20% 的程式碼包含了 90% 的 bug，任何團隊都可以告訴你哪個組件的問題最多，便可以從那個組件開始測試
7. 我們使用了多種程式語言，單元測試是否可行？
   • 可以，你可以用 C# 撰寫的測試，去測 VB.NET 開發的程式碼。
8. 軟硬體整合的開發
   • 多利用模擬器
9. 確保測試中沒有 bug 的方式
   • 你需要確保：測試在該失敗的時候失敗，該通過的時候通過
10. 偵錯器已經證明測試沒問題，還需要寫測試的原因
    • 偵錯器對測試多執行緒程式碼沒有幫助
    • 其他人的程式碼不確定性
    • 記住：從無到有撰寫程式，只是程式碼週期的第一步，接下來的生命週期，幾乎都在維護模式。
11. 測試驅動開發的必要性：
    • TDD 是一種方式上的選擇，有些人覺得很有價值，有些人覺得原本先撰寫產品程式之後再撰寫測試程式就很好了

小結

當你在看這本書，或這篇文章，代表在將來的某個時候，可能會需要在組織中開始進行單元測試，我們要為此做好準備，這會是一場艱難的奮鬥，理解影響力的力量，相信並堅持。

下一章，將討論遺留程式碼，並介紹適用處理遺留程式碼的工具和技術。