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

小結

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

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

#Unit Test #單元測試的藝術
也許你是單元測試甚至 TDD 愛好者,也許你著墨過一點單元測試,也許你是個剛開始寫程式的新手,不論你是誰,你都必須讀讀這本「單元測試的藝術」。 這是一本由 Roy Osherove 撰寫,針對靜態程式語言最經典的單元測試書籍。這個系列文會慢聊這本單元測試聖經,感受超層級的藝術。






Related Posts

Nginx + Flask 動態與靜態頁面分離入門教學

Nginx + Flask 動態與靜態頁面分離入門教學

kdchang
Day 3 - Javascript 教學

Day 3 - Javascript 教學

blinkchan
[Day00] 大綱

[Day00] 大綱

jinczing


Comments