添加单元测试对知名的旧版代码有意义吗？

• 我说的是TDD意义上的单元测试。（不是自动的“集成”，或者您喜欢称之为测试的东西。）
• 遗留代码，如：（C ++）没有测试的代码。（请参阅：Michael Feathers的“ 旧版代码有效工作”）
• 但是还有一些遗留代码，例如：我们的团队在过去10到5年中一直在使用的代码，因此我们通常对将事物放置在何处可以改变事物有一个很好的认识。
• 我们确实对某些模块进行了单元测试（通过Boost.Test），这些模块后来出现或很自然地适合单元测试（常见的应用程序特定容器，字符串填充，网络助手等）。
• 我们尚未进行适当的自动化验收测试。

现在，最近，我很高兴地实现了3个新的面向用户的功能。

每个人花了我大约1-2个小时来快速掌握我需要更改的代码部分，花了1-2小时来实现我需要更改的（小）代码，另外花了1-2个小时来确保应用程序之后正确运行，并且确实应该这样做。

现在，我确实添加了很少的代码。（我认为每个功能都有一个方法和一些调用行。）

分解出这段代码（通过WEwLC中建议的任何一种方法），以使单元测试变得有意义（而不是完整的重言式）将很容易又花费2-4个小时，甚至更多。这将为每个功能增加50％-100％的时间，而没有立即的好处，因为

1. 我不需要单元测试即可了解有关代码的任何信息
2. 手动测试的工作量是相同的，因为我仍然需要测试代码是否正确集成到应用程序的其余部分中。

当然，如果，以后，“有人”走过来，碰到的代码，他理论上可以有从单元测试的一些好处。（仅从理论上讲，因为经过测试的代码孤岛将生活在未经测试的代码海洋中。）

因此，“这一次”，我选择不做添加单元测试的艰苦工作：对代码进行更改以使要测试的东西要比对代码进行更改（要正确（清晰地）实现功能）复杂得多。

这是强耦合旧代码的典型代表吗？我是不是很懒？我们是否将团队的优先顺序设置错了？还是我谨慎，只测试开销不太高的东西？

您必须对这些情况保持务实。一切都必须具有业务价值，但是业务必须信任您才能判断技术工作的价值。是的，进行单元测试总是有好处的，但是这种好处是否足以证明花费的时间呢？

我总是会在新代码上争论不休，但是在遗留代码上，您必须做出判断。

您经常在此代码领域吗？然后有一个持续改进的理由。您要进行重大更改吗？然后可能是已经是新代码的情况。但是，如果您要在一个复杂的区域中编写单行代码，而这一区域可能一年都不会被再次使用，那么重新设计的成本（更不用说风险）当然太高了。只需在那儿拍一行代码，然后快速洗个澡即可。

经验法则：始终对自己进行思考：“ 我认为，我认为我应该做的事比我要求做的工作要多得多，因此我认为我应该从这项技术工作中受益更多？ ”

从TDD的角度讲，单元测试的好处是获得独立的东西，而无需一支稳定的团队多年来建立的口头传统。

幸运的是，相同的团队已经在同一个项目上进行了很多次了。但这最终将改变。人们生病，无聊或晋升。他们移动，退休或死亡。新的思想带有新的思想，并渴望按照学校学习的方式重构一切。公司被买卖。管理政策改变。

如果您希望项目生存下来，则必须为更改做准备。

编写单元测试可以将来验证您的代码。 如果代码库中没有测试，则应该为所有新功能添加新测试，因为这会使代码的一部分变得更健壮。

我发现，即使在旧版代码中添加测试，从中长期来看也是有益的。如果您的公司不关心中长期，我会寻找另一家公司。另外，我认为手动测试不需要花费比编写集合单元测试更长的时间。如果是这样，那么您需要练习专注于编写测试的代码。

当然，最佳实践表明您应该对更改的任何代码进行单元测试。然而，现实世界的编码涉及许多折衷，时间和材料是有限的。

您需要做的是，在不进行单元测试的情况下，按实际价值评估错误修复和修改成本。然后，您可以评估创建这些测试的投资。单元测试大大降低了未来工作的成本，但现在付出了代价。

最重要的是，如果您的系统很少更改，则可能不值得编写单元测试，但是如果需要定期进行更改，则值得。

所有这些不进行测试的理性决定都在累积着严重的技术债务，一旦有人离职并且必须聘请新员工并加快工作速度，这些债务就会再次困扰您。

是的，编写单元测试可能还需要花费2-3个小时的时间，但是如果代码从测试中退回，您将不得不再次手动测试所有内容，并再次记录测试-您不是吗？否则，没人会知道您测试了什么以及使用了什么值？

单元测试记录了代码的预期行为以及用于检查功能的测试数据，并使新编码人员有足够的信心确保他们在进行更改时未破坏某些内容。

与人工测试相比，今天的测试要花费几个小时，但是您每次进行任何更改都需要进行测试，从而节省了代码寿命。

但是，如果您知道该代码将在几年后退役，那么我已经说过所有更改，因为您将无法完成对代码的测试，并且永远都无法收回。

单元测试的价值不仅在于开发新功能时对其进行测试。单元测试的好处大部分是在将来获得的。

是的，您可能需要花费看起来过多的时间才能使旧代码可测试。

但是，如果不这样做，您将或者肯定应该花费很多很多小时来测试该功能。不仅是最初的开发，还包括软件的每个新版本。没有单元测试和其他形式的自动化测试，您将没有其他选择，而是要花费大量时间进行手动测试，以确保即使不更改功能本身，也不会无意中破坏您的功能。