※ 引述《ko27tye (好滋好滋)》之銘言：
: 我想補一個情境
: 當到新公司或轉到新單位時
: 發現沒有在做unit test
: 此時身經百戰寫過上千次unit test的你
: 會選擇憑一己之力
: 引入測試框架及補完所有模組的單元測試嗎？
: 當然這也代表那些高耦合的模組你要想辦法拆分
: 其中改壞了算你的鍋，改好沒人在乎
: 而且高機率你得自己維護測試code
: 還是選擇打不贏就加入？
: 我很好奇
: 大家可以分享一下嗎
: 我自己是選擇不改啦
底下這是比較「野性」」的作法，算是實務專案的經驗：
其實我覺得你到一個完全沒有測試的專案，要分兩個策略:
1. 補重要主線的 integration test 反正哪邊常被報修就補哪邊。
如果一開始補不上去就先做下一點，理論上常被報修的地方會一直出現在下一點，
累積多了就可以變成1了。
2. 假設自己是維護歷史功能，提昇自己維護部分的可測試性。
舉實際案例好了，假設我今天再做一個算金流手續費的專案，
發現過去算手續費假設有11個地方寫了11次好了，所謂的高耦合不外乎如此。
我會先寫個 util 把輸入跟輸出「去狀態化」，然後針對這個 util 寫，
然後這個 util 的單位以「去狀態化」成本可控，可在手邊開發時間允許的範圍進行。
白話文：我橫豎都得手動測試，那就把手動測試的部分，
盡可能的透過 test code 來進行。
如果不想接著維護的話也很單純，任務結束後把 test code comment 掉或移除就行。
題外話，11個地方，我會選擇先取代一個地方，
然後等其他10個地方有需求變更時，一個個整併，補強測試條件。
很多人會說，那為什麼不一次改11個，理由是你的開發時間跟成本允不允許。
更重要的是你的QA資源夠不夠，因為寫正常的Test最累的是準備測試情境，
這真的是會花掉比寫test更多的時間。
如果列不出完整場景，貿然修改既有的code只是在裸奔。
有需求的部分是被迫裸奔，但沒需求的部分不用主動當暴露狂，
等待驗證過再慢慢統一。
大原則就是：你橫豎都是要測試的，只是手測還是寫程式測，除了跟 gui 有關的東西，
多數的情況下寫程式測試都還是比較省時間的。
更棒的地方是，在這種策略下，你往往可以用比同事少30% 的時間完成任務，
而且因為你的測試成本比較低，所以品質也會比較好，出問題的時候也更容易對焦。
然後我通常是會跟同事說我寫了幾個 test case，
他們願意看就看，不願意看我就放著。不會勉強他們加入。
如果你做不到可以用比不寫測試更短的時間來完成任務，
那你學的測試根本性的就有問題，不寫也罷。XD
3. 極端情況： 如果都沒被報bug，需求也都很小？
那你操心他幹嘛 XD