难得看到这麽精彩的讨论, 而我非常同意 TonyQ 的看法 特别同意 1. unit test 不是各处都适用 2. unit test 不是万灵丹, 他只是用来取代人类重覆同一个动作容易出错的特性 3. unit test 视需求再配合其他的 QA 机制 这边补充一点我对 unit test 的想法 想像一家公司有 5 个 team 各自开发各自的 service 彼此之间是有相依性的, 但是彼此不见得会熟悉对方的程式 他们有共同的 continuous build system, 并且每次 build 玩也都会自动跑 unit test 当你的程式码通过 code review, 可以送进 repository 之後 你可以很容易的就知道有没有 break 别人的 build, 有没有 break 别人的 test case 如此便可在 release cycle 之间快速的决定要先 revert 还是能够提供 quick fix 想像这些 service 都是很花时间 deploy 并且需要复杂的设定让彼此相连的 有时候你只是想要很简单的测试是不是某个资料验证的 function 写对了 把 service 跑起来验证 (如果写错了还要重覆几次) vs 写你手动测会测的资料作成 unit test, 跑 unit test 好几次 这时候开发时间 / 测试时间的衡量之下, 就可能会让人喜欢上 unit test 再搬个教科书上的说法 unit test 是让这个模组的原作者写下该注意的事项 而手动验证常常是接棒的人, 甚至是不相关的人臆测做的测试 与其让不了解的人盲目的测试, 不如让清楚事件始末的原作者先立好标准 我自己是从怀疑, 学习, 一直到受到大量的好处之後 最後才相信 unit test 这种做法有其可取之处 了解了好处, 知道在什麽地方是他的着力点, 才能安心使用 此外, 建议先去了解现阶段的 unit test framework 能做到什麽事 并且了解一般来说要搭配什麽样的动作一起做 (continuous build ? code review ? ... etc.) 最後才是评估自身的需求, 是不是有需要建置这些系统, 是不是带来够多的好处导入需要多少的教育训练等等 这时候下定论要不要使用 unit test, 才不会误用 or 浪费 :) --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 140.112.30.32