PixelMage

前来给大佬顶贴

@index90
我个人的粗浅理解是，一些核心基础中间件之类的，单测,E2E 我觉得都不能少。
但是如果是一个业务系统的话，这可能就回到我提出的这个问题了~

其实我个人的小心思是：既然业务 e2e 测已经 work 了，异常流也 cover 到了，单测带来的代码健壮提升 i don't care，毕竟后面还有 IDE，语言框架，lint, 代码风格检查，开发规约拉着我。

这样可以提高业务的落地速度，但是要是说后续的可维护可扩展性的，写单测应该是会有提高的，但是提高多大，就不太好说了，估计每个业务系统可能都不一样。

还是特别感谢你的回复，我收获了不少东西~~对单测的看法也没有那么片面了

@index90

对于“业务系统是否应该写测试”，我觉得我们都是一致的，不写测试带来的都是短期的时间收益，和长期的整体研发效能损失。所以对于“为了开发速度牺牲质量——不写测试”，我也是觉得不可取的。

但是我更想知道的是“ [业务] 系统里只写 E2E 不写单元来达到时间和收益的最佳 tradeoff”是不是合适的？
我举一个量化的例子
我假设写 E2E 测试能 COVER 90%的业务 BUG，需要花费 1 个单位的时间
如果我再补上单元测试，能再补上 9.9%的业务 BUG，但是需要额外花费 1 个单元的时间

那么此时我认为，只写 E2E，不写单元是比较划算的。
这里有两个问题
1. E2E 测试能不能 COVER 90%的业务问题？
2. E2E 测试环境的搭建是否真的比单元测试简单？

其中
1.我觉得对于中小系统都是适用的，写完正常流和异常流的 E2E，我认为能够覆盖 80 90 的问题。
2. E2E 的测试环境，如今在各种中大型开发团队，比如阿里，都是日常、预发、线上，三套或以上环境 ，天然就有公司准备好的环境，不需要你再去搭建什么，所有的系统都遵守了这个规则，所以在中大型团队，我认为这个没什么成本。在小型团队，那可能写不写测试都是问题了。

综合来说，我想说的观点，一句话就是
“在大部分非核心中小型系统里，只写 E2E 测试是权衡了效率和质量的好选择”

@index90 感谢你的回答，真的，我困扰了很久。

确实如果你所说，我并没有考虑到下游没响应，数据库失败的情况，我只覆盖了业务的正常流和异常流。但我很好奇如何在单测里覆盖这些东西？不知道有没有 repo 可以参考一下（我是真的想学习一下，没有别的意思）

“业务逻辑覆盖是否有可量化指标，如何证明你覆盖了“所有”的业务逻辑呢” ——也只能尽量，毕竟总有黑天鹅，尽量的意思就是 1. 梳理出所有可能的业务异常情况并测试到 2. 测试覆盖率

“系统稳定并不只有业务逻辑，还有其他异常情况考虑”， “单元测试只是一种软件质量保证的手段，而且经过多年的考验
....你可以选择你的方法”——
没错你说得对，但是在日常的业务系统开发中，而不是伟大软件开发中，经常会出现为了开发速度牺牲质量的 tradeoff，我其实很倾向于“只写 e2e 是一种比较划算的 tradeoff”。另：我问一个我在阿里写 java 的同事这个问题，他说：哪有时间写什么测试，直接丢给测试同学。所以我觉得这种现象是常见的。理想情况下，当然是都写最好，但是现实世界往往不尽如人意。

再一次感谢你的回答~真的很认真，感谢。

@index90 想请教一下
在 e2e 测试覆盖了所有业务逻辑的情况下，
出于对业务系统稳定性的考虑，而不是代码逻辑优化的考虑下，
是否还有必要再写单测？

请教一下盈利或者收费计划是怎么样的？

@index90 学习了，感谢回复。可能是我现在的系统比较简单的缘故，我直接写 E2E 更快~

@kwrush 可能是我写的系统的比较简单，最多也就十来张表，CRUD，所以都是直接写 E2E 不写单测，最近产生了这个疑惑——“为什么还要写单测”