※ 引述《prag222 (prag)》之铭言：
: 坦白说unit test直觉上就是增加开发成本
: 我第一次写unit test觉得是在帮老板烧钱
: 我个人是觉得unit test不见得不需要每个功能都实作
^^^^^^^^^^^^
我猜您应该是想说，不见得需要
XD
: 把一些重要的功能逻辑,或有机会异动的程式码 做unit test会比较好吧
: 不然只做新增修查delete,这种操作应该不用写unit test
: 小弟不懂~觉得没啥用处,是因为遇到太多人只会嘴
: 用过后真的体会到它的好处的人不知道有多少
: 不然只会遇到一堆嘴上功夫而已
我认同您说的
重要逻辑做单元测试是比较好的
单纯 CRUD 也许可以不用做单元测试
分享我个人对单元测试的想法：
表面价值一，可以验证程式是否正确
不解释，而且程式可以帮我测好好的，我干嘛手测
表面价值二，修改或重构程式的时候，可以保护原本被测试的程式逻辑正确
1 个功能 5 个情境没什么
100 个功能， 5000 个情境，所以只好请工读生手测了
> 补充说明一下，我上面指的是手测会发生的状况。写单元测试当然无感XD
附加价值一，单元测试是在使用程式，写单元测试常会不自觉把程式修改得更好用
这写久了才会知道...
单元测试会想改的好写一点，然后“通常”程式就会比较好用
附加价值二，手测非常有可能会因为人的因素，影响程式品质，单元测试不会
举例：刚开发人员请我喝饮料耶，我等下测试一定要好好测/放水流
看公司规定，比方说 bug 算在开发人员头上，那就会好好测
如果 bug 来就只是修而已，那也许就会放水流
总之，上例情绪会是一种影响结果的因素，可是情绪不是程式码的一部分XD
讲这么多好处，来讲讲反面的场景，也就是不适用的地方
比方说一个小型专案要快速开发，但未来不会自己维护
那可能就像您说的，烧老板的钱，那确实不写测试会比较符合公司需求
但如果是公司开发一个要自己维护的大型产品，我还是会建议好好写测试