※ 引述《prag222 (prag)》之銘言：
: 坦白說unit test直覺上就是增加開發成本
: 我第一次寫unit test覺得是在幫老闆燒錢
: 我個人是覺得unit test不見得不需要每個功能都實作
^^^^^^^^^^^^
我猜您應該是想說，不見得需要
XD
: 把一些重要的功能邏輯,或有機會異動的程式碼 做unit test會比較好吧
: 不然只做新增修查delete,這種操作應該不用寫unit test
: 小弟不懂~覺得沒啥用處,是因為遇到太多人只會嘴
: 用過後真的體會到它的好處的人不知道有多少
: 不然只會遇到一堆嘴上功夫而已
我認同您說的
重要邏輯做單元測試是比較好的
單純 CRUD 也許可以不用做單元測試
分享我個人對單元測試的想法：
表面價值一，可以驗證程式是否正確
不解釋，而且程式可以幫我測好好的，我幹嘛手測
表面價值二，修改或重構程式的時候，可以保護原本被測試的程式邏輯正確
1 個功能 5 個情境沒什麼
100 個功能， 5000 個情境，所以只好請工讀生手測了
> 補充說明一下，我上面指的是手測會發生的狀況。寫單元測試當然無感XD
附加價值一，單元測試是在使用程式，寫單元測試常會不自覺把程式修改得更好用
這寫久了才會知道...
單元測試會想改的好寫一點，然後「通常」程式就會比較好用
附加價值二，手測非常有可能會因為人的因素，影響程式品質，單元測試不會
舉例：剛開發人員請我喝飲料耶，我等下測試一定要好好測/放水流
看公司規定，比方說 bug 算在開發人員頭上，那就會好好測
如果 bug 來就只是修而已，那也許就會放水流
總之，上例情緒會是一種影響結果的因素，可是情緒不是程式碼的一部分XD
講這麼多好處，來講講反面的場景，也就是不適用的地方
比方說一個小型專案要快速開發，但未來不會自己維護
那可能就像您說的，燒老闆的錢，那確實不寫測試會比較符合公司需求
但如果是公司開發一個要自己維護的大型產品，我還是會建議好好寫測試