unit-testing - 在一个庞大而古老(5 年)的代码库中进行单元测试是否值得？

Question

我刚刚加入了一个过去 5 年来一直在主要模式下工作的团队(基于 java、maven 的项目)。因此，利用单元测试的计划一直在筹备中，从未实现(到目前为止)。一个伟大的开发团队确保代码质量总体良好，不存在结构性代码问题，但只是没有编写 jnuit 测试的文化。但是，在看到单元测试的好处之后，我是这里插入采用自动测试的孤独战士。

团队布局是这样的，一个单独的测试团队在推出代码之前对功能进行手动测试，变更管理团队是变更批准和构建的检查门(到目前为止也没有持续集成)。

以下是障碍: 由于代码库庞大，并且一些原始开发人员已经离开团队，任何额外的单元测试可能太少、太晚。
此外，我可能是唯一一个插入单元测试的人。尽管我的经理一直支持这个想法，但他不希望变更团队因运行测试所需的额外时间而陷入困境。

我认为可以使用独立的 CI 工具开始，变更团队必须在添加测试时更改他们的脚本以跳过测试。

你会在我的鞋子里做什么？

P.S.:我知道 stackoverflow 上有一个类似的问题，但在这一方面，目的是说服不同的利益相关者并采取最佳途径；不是技术比较。

Answer 1

听起来你对这种情况有很好的把握。

两件事情:

不要期望能够对一个已有 5 年历史的项目进行完整的单元测试。假设 5 个开发人员工作了 5 年，那么您大约有 50,000 个程序员小时。假设测试花费的时间与编写代码的时间一样多，那么一年内获得 2-3% 的覆盖率就不错了。

所以:测试新代码，并为旧代码的修改编写测试。花时间/花时间来设置某种 CI。渐渐地，您将建立一系列不错的测试。

因为你显然没有被错误淹没，所以慢慢开始，获得动力。