這位前輩你好，小弟有些不同的意見
※ 引述《accessdenied (存取違規)》之銘言：
: 單元測試有時候反而破壞程式碼的易讀性和維護性
: 因為要做到單元測試，就得斷開所有的相依性
就算沒有單元測試，"高內聚，低耦合"的原則，也應該是適用的
所謂斷開相依性更準確地說應該是"相依於抽象而非具體類別"
Design Pattern有80%以上的pattern都是在做這件事
: 而對抗相依性，作法就是引入 DI。但是 DI 就會增加代碼閱讀和維護的複雜度。
: 舉例來說，如果代碼內有時間上的相依性，例如用了 DateTime 物件取得現在時間做某些
: 判斷，原本可以很簡單的寫出易於閱讀和維護的邏輯：
: If (DateTime.Now > 12:00:00) then return “PM” else return “AM”;
: 為了讓單元測試可以控制驗證條件，只能
: Interface IDateProvider { virtual GetNow(); }
: Class DateMock : IDateProvider { GetNow() { return 13:00 }
: IDateProvider dateProvider = container.Build(....);
: If (dateProvider.GetNow > 12:00:00) then return “PM” else return “AM”;
: 然後再搞個 config 想辦法讓程式吃到你寫的 DateMock 類別....
: 上面是sudo code 就不用討論語法細節
以您提的DateTime為例，若If那行出問題，沒有單元測試的情況下
我們可能沒法馬上知道錯的是DateTime，還是比較的邏輯(可能是>寫成<)
小弟以為單元測試的好處就是在測某個功能時，可以用Mock確保其他東西都是正常的
這樣有錯誤才好抓出來
多加一個IDateProvider有另一個好處是可以應付DateTime不只一種的狀況
例如TaiwanDateTime和USDateTime
: 這就是單元測試的代價！程式真的會比較容易閱讀嗎？
"理想上"的狀況是測試程式本身就能明確表達出需求
讓人能夠只看測試程式而不用去trace又臭又長的商業邏輯就能大概知道整隻程式在幹嘛
: 單元測試要花在切除相依性的條件花費的成本時間遠高於撰寫production code
: 而且你的 production code 能不能賺錢還不知道咧？
: 到底需不需要單元測試和 clean code ？ 先搞清楚寫的用途和目的，你寫的東西有沒有
: 真正的商業價值再說吧。
商業價值跟有沒有單元測試或clean code，應該是沒有相關的
總不是說一個本來會賺錢的專案因為寫了單元測試就不賺錢了吧?
況且單元測試本身就是為了減少開發與維護成本所出現的東西
: 不要把 clean code 和 TDD 無限上綱了
: 工程師最容易自嗨就是這樣，還會自以爲「這是專業」？
: 乞丐的乞討專業比我們強也不會產生「價值」。
就我遇到的狀況都是"我們不要搞那些了，程式能動就好"
倒還沒聽說過因為用TDD，測試程式寫太多拖累整個專案的事情...
寫出易讀、易維護的程式碼也是軟體工程師的職責之一吧!