閱讀筆記：The Art of Unit Testing Chapter 11 Integrating unit testing into the organization

2024-02-08 17:52 Testing

簡介

本章為「想要帶來改變」的人整理了三個注意事項：

幫手（champions）：指那些願意接受改變的人，他們通常都懷抱著開放的心態。有些人甚至就有嘗試導入改變的經驗——若是如此，請記得向他們請教：

擋路者（blockers）：指那些寧可保持現狀的人。面對擋路者，你要盡量讓他們成為改變的一份子——讓他們協助你規劃、制定新規則，重點是讓他們感受到自己被依賴、對團體產生貢獻。

與同事討論後的感想：擋路者不等於反對者。能說動中立份子加入你就不錯了，不要期待能說服反對者加入你的陣營 🤡

建議從小規模、低複雜度的專案開始比較好——尤其是初次嘗試推動改變的人，請將計畫規模限制在自己能力可及的範圍內。另外，從小型專案起手，也能避免在計畫不幸失敗時產生無法負擔的代價。

在你制定計劃時，請搜集足夠多的資訊來證明改變帶來的優勢會遠多於缺點。試著挑自己計畫的毛病，並針對這些尖銳問題找出合理的解答——因為一定會有人問這些問題。

以單元測試來說，常見的問題有：

撰寫單元測試會增加開發的時間：這是事實。但單元測試能確保「在我們有預想到的範圍內，產品的功能都會符合預期」，這能減少產品上線後的錯誤數量，也能減低日後除錯、重構的時間成本。整體而言，開發的時間會變長，但維護與除錯的成本都會下降
你這是在搶 QA 的飯碗：不盡然。單元測試著重驗證「一個單元的行為是否符合規格」，但沒有驗證「當一堆單元組合起來後，整個產品的操作流程是否依舊流暢」——而後者是 QA 可以集中火力檢視的部分
為什麼你花時間寫了測試，但產品還是會發生問題：同上，只有寫單元測試的話，就只能確保一個單元的功能正常，沒有保證產品的使用流程
這麼大一包程式碼，到底要從哪裡開始：推薦從「最常出現問題的模組」開始導入單元測試

擬定暫時性（例：為期三個月）的導入計劃，訂定可量化的目標並持續公布、追蹤之，確保計畫有為專案、產品帶來正面影響。如果沒有顯著改善，那就確實終止計畫，讓大家回到過去的作業方式。

不必堅持計畫一定要完全根據你的腳本進行，如果其他操作方式也能實現你的目標，那就放手讓大家去做。

申請外部資源（例：顧問）來主持計畫。請外人協助的優勢是：沒有發言包袱、（或許）較多的計畫導入經驗，以及明確的時間限制與成敗判斷標準。

本書作者認為「缺乏持續改變的推力」是造成改變失敗的頭號原因。作為改變的推動者，你必須意識到自己就是得貢獻時間在教導、推廣、解決他人在計畫裡遇到的問題。

引入外部資源可以緩解這種過度燃燒自己的問題。

另外兩個可能造成改變告吹的要素如下：