单元测试是否值得在大和老的（5年）代码库中付出努力？
我刚刚加入了一个团队，这个团队在过去的5年中一直以main-always模式工作（java，maven based project）。 因此，计划利用单元测试一直在进行中，从未实现（到目前为止）。 伟大的开发团队已经确保代码质量总体上良好，并且没有结构性代码问题，但是没有编写jnuit测试的文化。 但是，在看到单元测试的好处之后，我在这里推动采用自动测试。
团队布局使得单独的测试团队在推出代码之前对功能进行手动测试，并且变更管理团队是变更审批和构建的检查门（到目前为止还没有持续集成）。
以下是障碍：由于代码基础庞大，并且有些原始开发人员已经离开了团队，所以任何额外的单元测试可能太少，太迟。 再加上我可能是唯一一个推动单元测试的人。 虽然我的经理一直支持这个想法，但他不希望更改团队因测试运行所需的额外时间而陷入困境。
我认为独立的CI工具可以用来开始，而且变更小组必须改变他们的脚本以跳过测试，并且当它们被添加时。
你会在我的鞋子里做什么？
PS：我知道关于stackoverflow的一个类似的问题，但在这个问题上，目的是说服不同的利益相关者和最好的takel路径; 不是技术比较。
听起来你对这种情况有很好的把握。
两件事情：
不要指望能够完全测试一个5年前的项目。 假设有5位开发人员工作了5年，那么你的程序员工时间就在5万个左右。 假设测试需要花费尽可能多的时间来编写代码，那么在一年内获得2-3％的覆盖率将会非常好。
所以：测试新代码，编写测试以修改旧代码。 花时间/花时间设置某种CI。 逐渐地，你会建立一个很好的测试电池。
既然你显然没有淹死虫子，那就慢慢开始，增加动力。
值得编写测试来测试你正在工作的特定功能，并且你想保持稳定。
对于目前没有测试覆盖率的大型现有应用程序，您不希望坐下来一次性编写测试，以获得100％的单元测试覆盖率，您永远也不会。 您只需选择特定的功能进行测试。 我不认为这样的事情太少或太迟; 对于只有一点非常重要的功能的单元测试总比没有单元测试好，现在一些单元测试比没有单元测试要好。
单元测试甚至在旧项目中都是有利的，例如，通过建立单元测试，您可以确定问题不在现有代码中，而是在新代码中（即使您有质量保证流程，错误仍然会在时间）。 此外，它们可以防止对旧代码的更改引入细微的行为差异。 此外，单元测试记录了庞大代码库的预期行为。
现在，采取大的改变是不容易的。 第一个也是最直接的事情是要求对所有新代码进行单元测试，以便单元测试旧代码库的工作量和工作量不会不断增加。 然后，第二部分是主动，为旧代码创建一些单元测试。 如果你这样做了，那么你应该能够说服你的团队的其他成员帮助为现有代码创建单元测试。 如有必要，可以提出有趣的激励措施，比如承诺为团队提供比萨派对，为现有代码库创建最大数量的单元测试。
另外，提醒你的队友，这不是他们需要放弃他们正在做的一切的东西......如果他们每天只在其他工作上为现有组件创建一个单元测试，那么最终你会得到为代码库中的所有现有组件进行单元测试。
链接地址: http://www.djcxy.com/p/50811.html上一篇: Is Unit Testing worth the effort, in a large and old (5yr) codebase?