@GallifreyCAR 单元测试只能保证你的代码段没问题，业务流程、需求偏离这些一点都不可能覆盖到。微软没测试，首先你老板要不要看看 windows 现在系统更新是个什么鬼样子，让他搜搜 win10 更新那些鬼故事

首先不论是什么方法这个肯定是需要一定是时间改造项目，领导接受不了那就放弃 测试的话数据库可以不用 mock ，直接跑个测试用的每个 unit test 自己准备表和数据，跑完删表 和外部的调用就没办法了，只能改成依赖注入然后 mock

你觉得在一样的工作时间内，能在保证代码质量和规范的前提下让开发写足够数量和质量的单元测试吗？

go 的话使用 Monkey Patching 很简单做单元测试啊，直接把对应的函数打桩就好了，很久之前一个项目也是用全局变量面向过程一把梭

@GallifreyCAR 如果测试并不对代码进行测试，只是进行黑盒测试 我觉得单元测试并不能替代 原因： 1.单元测试只是对代码分支的覆盖性测试，只对最小单元的代码逻辑负责，不对实际功能负责。 2.我以前经历过的项目中，单元测试会被领导层以覆盖率为唯一指标进行追踪，导致开发人员编写大量的测试用例来覆盖所有分支，对正常开发进度严重干扰。 3.单元测试的高覆盖率不等于软件整体功能的高可用性，这也是我之前那个项目中出现的问题，单元测试覆盖率很好看，但是功能测试中仍然出现大量 bug 。 所以单元测试和功能测试不是替代关系，功能测试这种点点点的测试是必须的，要优化也是把功能测试的实际测试部分 RPA （自动）化，减少部分人力投入。 至于测试用例部分，未来可以考虑通过 AI 自动生成，但现阶段我觉得可行性需要再研究。 但测试自动化这块其实应用上已经相对成熟了，可以考虑做导入。

我刚才工作的时候, 必须要写单元测试. 后来前后端分离 就没人写了

根本问题是要加排期

推单测没问题，想用单测完全替代测试有点难吧

单元测试只有国内互联网公司做的好一点，其他公司很难执行下去。 在互联网公司，项目的特点是时间紧，任务重，项目先上，等后面不忙了，再补单元测试跟文档。 就这样，一直都是紧急需求，已经有好几年的单元测试跟文档没补了。

你们的什么业务需要单元测试？不是核心业务搞单元测试成本你们盖的住不？就算都是 AI 写代码，后续还要有专人维护单元测试，需求稍微变动一下，单元测试就要重新更新。能支付这种成本的一般都是金融行业或者核心产品，代码修改如果没有单元测试验证，很难直接上生产。因为金融行业一旦出现 bug ，就是金钱的损失，不敢没有单元测试。