在我上一家公司，我们绘制了故障发生时间与各服务测试覆盖率的图表

你认为早期的初创产品可能是个例外吗？ 因为整个功能可以被快速舍弃，甚至有时整个产品都会转型。

虽然我同意测试总体来说是必须的，但我仍然不认为单元测试是通用的工具。 对于核心库或编译器之类的东西，当然单元测试很好。但对于更上层的代码，我倾向于首先进行集成测试，然后在需要的时候再添加单元测试。 毕竟，你不能没有集成测试。不管你的乐高积木有多完美，你仍然可能错误地将它们组合在一起。

- 考虑清晰的接口 - 明确处理边缘情况 - 创建清晰的责任分离 - 建立正确的启动/关闭流程 但如果一开始你就做到了所有这些事情，那么它的价值主张又是什么呢？

我认为测试作为一种成本，和手动QA也有另一种成本。根据时间成本（维护或手动QA）和前期成本，以及重构的风险，需要测试，有时一种选择会比另一种更好。这会变化，所以值得考虑。

就我而言，浏览器中的端到端测试对于有很多部分需要集成的服务真的很有帮助，但它们很难变得可靠。 一个挑战是动画和时间竞争，据说是Playwright可以解决其中很多问题。另一个是某些基础设施，比如GitHub Actions可能会随机资源不足，比如导致Chrome Driver无响应。自动重试是一种解决方法，但代价是可能会掩盖罕见的时间竞争和问题。 当然单元测试很好，快速且范围小。但重构可能会使大量测试变得过时，而且它们无法证明各部分作为一个整体是否正常工作。

> 最有洞察力的观点是测试如何从根本上改善你的设计。当你必须让某样东西可测试时。 当人们说这类话时，我认为这有点像代码异味，说明他们测试的层次太低，并且他们的测试与实现紧密耦合。 确实，你的代码与测试和实现紧密耦合所带来的痛苦，可能会促使你解开一些这种紧密耦合，但这仍然使你的测试和代码紧密耦合。 我发现最值得的回报是那些在足够高的层次上运行的测试，这样可以让你安全地进行大量重构，同时只需最少的测试更改。由测试覆盖的技术债务不会以同样的速度累积。

这是原帖作者。感谢如此深入的评论和反应。我很高兴我"触动了某人的神经"！