※ 引述《prag222 (prag)》之铭言：
: 坦白说unit test直觉上就是增加开发成本
: 我第一次写unit test觉得是在帮老板烧钱
: 我个人是觉得unit test不见得不需要每个功能都实作
: 把一些重要的功能逻辑,或有机会异动的程式码 做unit test会比较好吧
: 不然只做新增修查delete,这种操作应该不用写unit test
: 小弟不懂~觉得没啥用处,是因为遇到太多人只会嘴
: 用过后真的体会到它的好处的人不知道有多少
: 不然只会遇到一堆嘴上功夫而已
Unit Test跟其他自动化测试需不需要，先得看你是什么专案
如果是那种完全不在乎品质，交货后的维护也不干你们的事
连手动测试都没在做或随便做做的那种专案，写一堆烂code会动能收钱就好
那还真的没什么做的必要
不过这种专案应该不是太多，而且有志往软件技术深耕的人应该也不会太想待这种专案
如果是那种后续维护都要你们负责，或是做产品的，出去就要卖好几年，改很多版的
那你多半需要做Unit Test跟其他自动化测试
Unit Test的主要目的并不是在"当下"找出问题
虽然你多多少少会透过它在当下找到问题
但它主要目的是在之后无数次的变更中，告诉你你的新code有没有把原本的功能搞烂
如果没有它，这件事就是手动做
而一个有规模的专案，手动做一次至少是好几个人X好几天，甚至几星期
又或者是不做，然后烧香拜佛祈求不要出包
而这会造成一个延伸的效应，就是案子愈久愈没有人敢去大幅度的改code或是refactor
大家改变愈做愈小，最后都是在那边治标不治本，久了就愈来愈难维护
而从开发者角度，其实最大的好处是帮助我把code架构写得更好
因为如果code的藕合度太高，会非常难unit test
所以写unit test会自然让人写出比较低藕合的code
当然也可以写高藕合的code然后用一堆mock，但是用太多mock本身就是不好的做法了
Unit Test跟其他自动化测试主要是帮你把测试的成本降低，还有提升品质
所以如果你的成本算法是"开发+测试+解bug"，那么做这些是有用的
但如果你的成本算法是"开发"然后没了，那或许就没用了
之所以会有它增加成本的错觉，是因为他增加开发这段的时间
但是它增加的时间会在后面的测试还有解bug加倍还回来
只是一般比较差的团队，都只有估开发时间
后面的虽然都有做，但是都不估的，好像不用时间一样
所以估算一出来当然就觉得好像增加了成本