单元测试有必要吗？

[RuLaiFo]

单元测试有必要吗？

我在现在的公司工作近半年了，公司的项目都需要写单元测试。但是写了这么久，感觉写单元测试费力不讨好，有时候写单元测试的时间大于写业务逻辑的时间，需要 mock 一大堆数据。要保证各种覆盖率，特别是分支覆盖率，需要覆盖到所写的每一个分支。

另外，大家写的单元测试质量参差不齐，因为感觉大家都是为了写测试而写测试，而不是真正的 tdd 。然而在迭代频繁，节奏紧凑的环境下，想要做到真正的 tdd ，还是有很大的难度的（个人觉得 tdd 实现需求会花更多的时间，可能是自己没正确认识和掌握 tdd?）。所以这就导致大家往往先去实现逻辑，再去写测试。

简而言之就是认为单元测试费时费力，又没有明显的收益，想请教一下大家怎么看待单元测试。

初次提问，如有不恰当的地方，请大家指出。

[chendy]

单元测试主要是能让人改东西的时候放心一些，改完了之后跑一下测试就知道有没有破坏之前的逻辑
越重要的功能越有必要写单元测试，盲目追求覆盖率不可取，毕竟大多数项目成本有限

[matrix1010]

实际上没多少公司是 TDD 的，但不代表不需要单元测试。看看大佬怎么说 https://twitter.com/mitchellh/status/1458478408749309960?s=21

[vishun]

现在安排你改个逻辑，然后部署到生产环境上，如果生产环境出错，可能就影响非常多的客户使用、可能造成真金白银的损失。你能确定你改的这个逻辑对其它的逻辑没有影响吗？你部署时不忐忑吗？单元测试最起码能检测出最基础的错误来。
当然小公司、内部使用，没多少人的话随便了。

[dongcidaci]

能百分之百保证自己写的代码没毛病吗，老铁

[janxin]

先去写逻辑再去写测试一般是增加 TDD 成本的最大元凶，先写测试就会提前考虑代码如何方便进行测试。另外写测试代码大于写业务代码时间是十分正常的事情，所以计算时间点的时候要预留出对应的空间。覆盖率在互联网开发团队可能是一个可以 trade-off 的东西，是要看团队的基线在哪里。落地 TDD 跟时间节奏有很大关系，如果项目本身就很时间紧张，那么 TDD 势必会导致两种选择：放弃 TDD 和项目延期。不过这个看情况是不需要你来决策的内容。

至于 TDD 的收益网上有很多文章介绍了，不如看看网上的文章，然后想一想：这些收益对我来说重要嘛？

另外，即便没有 TDD ，也一定要有集成测试

[yishanhe]

如果把 e2e,integration,unit tests 从上往下排起来，有人推荐应该是金字塔形（侧重在单元测试），也有人说应该是棱形（侧重在集成测试），我的经验是如果集成测试框架好，可以多写集成测试，单元测试重点保障关键的 local 逻辑，然后一定要有 coverage tool 这样只要综合的 coverage 够就行了

[shateiel]

我不爱写单元测试，但是我发自内心的觉得单元测试很重要。

[VeryZero]

如果规模较小，质量要求不高的项目确实没有必要。

但是如果大规模，高质量要求的项目，没单元测试就会陷入 BUG 越修越多的情况。。

[RuLaiFo]

@chendy @vishun @dongcidaci

这个赞同，可以改的放心。但是除了单元测试，上线前都会有 QA 进行测试，不过也可能有漏测。

其实也会有许多公司不会严格执行单元测试，甚至不写单元测试，不知道一线大厂会不会不写单测？但是他们的项目其实也在正常运行，迭代，似乎单元测试又显得不那么重要了?

[cmdOptionKana]

你想想，你去改别人的代码，没有单元测试，改完心里没底啊，如果手动测试，花的时间也不少。

别人改你的代码时，心情也一样。

你现在每天对着同一个项目折腾，当然对它很熟悉，但是如果你隔半年一年再回头看，也会感觉代码改起来心里没底。

小项目、初期开发需求变化剧烈、赶着上线、人手不足等等情况，可以暂时不写单元测试，但后续能补上最好还是补上，尤其是需要长期维护的项目，写单元测试的收益大于成本。

[pony187]

@shateiel 甚合我意^_^

[xtinput]

写好单元测试后期修 bug 和维护的时间简单点，特别是颠覆性的维护的时候

[ulosggs]

碰到不写测试的队友和不懂测试重要性的 leader 就很烦。不想干活儿。

[dingyaguang117]

1. 迫使你思考边界
2. 自测出低级 BUG ，甚至是语法问题
3. 便于重构后快速验证

感觉 3 的持续性价值最大，很多情况是明知道系统是屎山但是又不敢动，如果有完善的测试用例是十分有利于开展重构工作的

[binux]

如果你的代码不能被单元测试，那么你的设计有问题。

[RuLaiFo]

@chendy @yishanhe
是的，我个认为也不能盲目最求覆盖率，应该有所权衡，对复杂逻辑进行严格测试就行，毕竟时间有限。但是哪种属于复杂逻辑是个模糊的概念，我想大部分人都不喜欢写单元测试，这样往往就会有偷懒不写的心理。

[RuLaiFo]

@dongcidaci 即使有单元测试也不敢保证 100%呀，老铁，只是有单元测试，bug 概率更小😹

[milkleeeeee]

同意 15 楼的说法。我自己开发的软件之前也不写单元测试，后来改之前写过的代码的时候总是出 bug ，所以之后的代码我都会写单元测试。另外，单元测试能帮助我将代码进行拆分，以前我总是把大段大段代码写在一块，后来从单元测试的角度来思考之后，就会下意识的把一个功能分解成很多小的功能

总的来说我觉得虽然花的时间多了，但有了安全感、代码之间的松耦合度更低，更容易复用了，我觉得是值得的

[RuLaiFo]

@binux 不是代码能不能被单元测试，而是思考单元测试的重要程度和必要性

[liveoppo]

关键业务部分写单元测试即可，处处写是追求形式，极大增加成本。

尤其前端，如果业务的实现在前端，该业务部分写一下，如果只是展示后端送过来的内容，不用写单元测试。

你还没写好单元测试呢，可能产品或 UI 就过来推翻方案重新设计了。