在大型(5年代)代码库中,单元测试值得付出努力吗？

Question

我刚刚加入了一个团队,这个团队在过去的5年里一直在主要模式(java,maven为基础的项目).因此,利用单元测试的计划一直在进行中,从未实现(到目前为止).一个伟大的开发团队已经确保代码质量通常很好,并且没有结构代码问题,但是没有编写jnuit测试的文化.但是,我看到了单元测试的好处,我在这里推动采用自动测试.

团队布局使得单独的测试团队在推出代码之前对功能进行手动测试,并且变更管理团队是变更审批和构建的检查门(到目前为止还没有持续集成).

以下是障碍:因为代码库很大,而且一些原始开发人员离开了团队,所以任何额外的单元测试都可能太少,太晚了.除此之外,我可能是唯一一个推动单元测试的人.虽然我的经理一直支持这个想法,但他并不希望变更团队因测试运行所需的额外时间而陷入困境.

我认为可以使用独立的CI工具开始,并且变更团队必须改变他们的脚本以跳过测试,当它们被添加时.

你会穿什么鞋子？

PS:我知道在stackoverflow上有一个类似的问题,但在这个问题上,目的是说服不同的利益相关者和最佳的接受途径; 不是技术比较.

Answer 1

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

两件事情:

1. 不要指望能够对一个5岁的项目进行全面的单元测试.假设有5名开发人员工作了5年,那么你就要在5万个程序员小时附近工作.假设测试需要花费尽可能多的时间来编写代码,那么在一年内获得2-3%的覆盖率你会做得非常好.

2. 因此:测试新代码,并编写测试以修改旧代码.花时间/花时间设置某种CI.渐渐地,你会积累一大堆测试.

因为你显然没有淹没在虫子中,所以开始慢,获得动力.