单元测试 – 单元测试值得付出努力,在一个大而老(5yr)的代码库中

发布时间：2020-12-15 00:03:11 所属栏目：Java 来源：网络整理

导读：我刚刚加入了一个在过去5年( java,maven为基础的项目)中一直以主要模式工作的团队.因此,使用单元测试的计划一直在进行中,从未实现(到目前为止).一个伟大的开发团队确保了代码质量一般都很好,没有结构性代码问题,但是没有任何文字的写作测试.但是,我看到了单

我刚刚加入了一个在过去5年( java,maven为基础的项目)中一直以主要模式工作的团队.因此,使用单元测试的计划一直在进行中,从未实现(到目前为止).一个伟大的开发团队确保了代码质量一般都很好,没有结构性代码问题,但是没有任何文字的写作测试.但是,我看到了单元测试的好处,是一个孤独的战士,推动采用自动测试.

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

以下是障碍：由于代码库庞大,并且一些原始开发人员已经离开了团队,任何额外的单元测试可能太少,太迟.
加上它,我可能是推动单元测试的唯一一个.虽然我的经理一直支持这个想法,但他并不想让变革团队被测试运行所需的额外时间陷入僵局.

我认为可以使用独立的CI工具来开始,而且变更团队必须改变脚本,以便在添加时跳过测试.

你会在我的鞋子做什么？

我知道stackoverflow 上有一个类似的问题,但是在这个问题上,目的是说服不同的利益相关者和最好的道路.不是技术比较.

解决方法

听起来你对这种情况有很好的处理.

两件事情：

>不要指望能够完全单元测试一个5年的项目.假设5位开发人员工作了5年,你的工作时间在5万个左右.假设测试需要花费大量的时间来编写代码,那么您将在一年内获得2-3％的覆盖率.
所以：测试新的代码,并编写测试以修改旧的代码.获取时间/花时间来设置某种类型的CI.渐渐地,你会建立一个很好的测试电池.

由于你显然没有淹死臭虫,开始缓慢,获得势头.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!