我刚刚加入了一个团队，这个团队在过去的5年里一直在以主要模式工作（java，maven为基础的项目） . 因此，利用单元测试的计划一直在进行中，从未实现（到目前为止） . 一个伟大的开发团队确保代码质量总体良好，并且没有结构代码问题，但是没有编写jnuit测试的文化 . 但是，我看到了单元测试的好处，我在这里推动采用自动测试 .
团队布局使得单独的测试团队在推出代码之前对功能进行手动测试，变更管理团队是变更审批和构建的检查门（目前还没有持续集成） .
以下是障碍：因为代码库很大，而且一些原始开发人员离开了团队，所以任何额外的单元测试都可能太少，太晚了 . 除此之外，我可能是唯一一个推动单元测试的人 . 虽然我的经理一直支持这个想法，但他并不希望变更团队因测试运行所需的额外时间而陷入困境 .
我认为可以使用独立的CI工具开始，并且变更团队必须改变他们的脚本以跳过测试，当它们被添加时 .
你穿什么鞋子？
P.S . ：我知道stackoverflow上有类似的问题，但在这个问题上，目的是说服不同的利益相关者和最佳的接受途径;不是技术比较 .
6 回答
听起来你对这种情况有很好的把握 .
两件事情：
不要指望能够对一个5岁的项目进行全面的单元测试 . 假设5名开发人员工作了5年，那么你的工作时间在5万个小时左右 . 假设测试需要花费尽可能多的时间来编写代码，那么在一年内获得2-3％的覆盖率你会做得非常好 .
所以：测试新代码，并编写测试以修改旧代码 . 花时间/花时间设置某种CI . 渐渐地，你会积累一大堆测试 .
因为你显然没有淹没虫子，所以开始慢，获得动力 .
值得编写测试来测试您正在使用的特定功能，并希望保持稳定 .
对于目前没有测试覆盖范围的大型现有应用程序，您不希望坐下来一次性编写测试以获得100％的单元测试覆盖率，而您永远不会 . 您只需挑出特定的测试功能 . 我不认为有太少或太晚的事情;对于一小部分非常重要的功能的单元测试总比没有好，现在一些单元测试比没有单元测试好 .
单元测试即使在旧项目中也是有利的，例如，通过 Build 单元测试，您可以确定问题不在现有代码中，而是在新代码中（即使您有QA过程，错误仍然可以通过实施） . 此外，它们可以防止对旧代码的更改引入行为上的细微差别 . 此外，单元测试记录了巨大代码库的预期行为 .
现在，采用大变化绝非易事 . 第一个也是最直接的事情就是要求对所有新代码进行单元测试，以便单元测试旧代码库的工作量和工作量不会继续增加 . 然后，第二部分是主动，并为旧代码创建一些单元测试 . 如果您这样做，那么您应该能够说服团队的其他成员帮助创建现有代码的单元测试 . 如果有必要，可以提出有趣的激励措施，例如为团队承诺为现有代码库创建最大数量的单元测试 .
另外，提醒你的队友，这不是他们需要放弃他们正在做的事情的东西......如果他们每天只在他们的其他工作上为现有组件创建一个单元测试，那么最终你会得到一个对代码库中所有现有组件进行单元测试 .
恕我直言，单元测试或任何其他测试（功能测试除外）应该同时针对关键和易变的部分应用程序运行 . 换句话说，单元测试不应该是为了编写测试而编写的，而是为了确保开发/维护工程师不会在代码中的某些条件下跳闸 .
也就是说，您可能还想查看在CI服务器中运行的集成测试，更多是因为它们更接近功能测试，并且还因为代码已经成熟 . 根据我的观察，识别单元测试以在成熟的应用程序中编写是非常困难的，并且在短期内比集成测试具有更少的RoI .
在您的情况下进行集成测试将确保应用程序的各个层继续与意图一起保持原始开发者 . 另一方面，单元测试本质上更加本地化将确保特定区域中的任何新补丁/错误修复确实在该位置引起副作用 .
这将是一项巨大的努力，回报会很小 . 而是自动化和扩展您当前的测试以确保系统稳定性（我假设在系统级别进行了一些测试） . 我认为你应该把重点放在仍然看到很多变化或者你计划在不久的将来改变的系统部分 .
单元测试很好，但很难改装到现有系统中 . 如果您只关注明年或更长时间的单元测试，那么您将失去前进的动力 .
我不会写测试只是为了编写测试 . 什么是业务收益？您的企业可能已经遭受了没有进行单元测试的影响，现在问题已得到解决 . 如果我确实添加了测试，我只会将它们添加到会导致最不愉快结果的代码部分 . 例如，我考虑为任何角色/安全相关代码添加测试 .