betaparticle的部落格

客戶的小朋友問有沒有在用 unit test，原因是他看到別人也在用，沒用就感覺怪怪的。

這個我也想過一陣子。

最近又在 DevOps 社團看到有人抱怨，不要再看到「我的環境跑起來沒問題」的言論。

我把這兩件事聯想到了一起。

究竟，發展這工具原來是想解決什麼問題？你要用這些工具解決你什麼問題呢？

畢竟，工具是用來解決問題的，不是用來製造問題的。為了使用工具而造成更多問題，甚至原來的問題也沒有解決，又何必呢？

講個小故事，某個大公司開了個專案要將新的機台接進原來的系統，那個系統已經是二十年前的系統，原來寫程式的人都已經變成部門副理了。

要開新專案是因為人太忙，說是每接一台就要花掉半年，他們不是不會，只是沒空。

當我進去專案之後發現，之所以要花這麼多的時間，是因為做的人是新來的人，對系統不熟，只敢照抄，只敢小小改個一兩行確定不會弄死整個系統。

原因是他們沒有測試系統，都是在正式運營的系統上建假資料，接新程式測試，一但資料給錯，有可能整個資料庫的資料完整性有錯就鎖死，所以修改程式非常耗時跟痛苦。

當然，後來在我要求下，測試用的系統建起來了，他們公司的所有人對於系統敢於嘗試，進度就快了起來，也把一些以前程式做了優化及驗證。

回到 unit test 與 DevOps 的話題，這兩個的目的是希望增進程式的品質，並且利用自動化的工作方式提升品質與效率。

但若是那些自動化的工具，在使用及學習上反而降低了工作效率，或是沒有反映在品質上，又何必呢？

unit test 也是人寫的，那個也是有品質的，程式碼要 review，unit test 也是要 review 的，是否追求所謂的覆蓋率或達成率，本末倒置了呢？

最終，影響品質的還是寫的人，把人培養到可以信任才是最終目的。工具只是輔助，跟左手一樣。

回到 unit test 的話題，我最後的回答是，我們公司在開發階段，就已經建立了上層與下層的模擬器，中間在寫的過程也幾乎每個 function 都通過流程測試，資料也是理想中應該要有的資料，且正常流程、異常流程也都走過。也就是開發完之後，模擬環境下的整合測試都做完了，unit test 能增加的效益應該不高。

以往我以為所有的公司都是這樣開發的，但現在知道，有跟我們合作過的人，有做到的不算多。

要做到這樣，不是有 unit test 或 DevOps 工具就行的，而是需要與程式系統規畫的責任分割、公司的經驗與文化一起配合來達成程式品質的保證。

講得好像自己很高尚的樣子，其實只是在我這小小眼界裡看到的相對比較而已。