添加单元测试对著名的遗留代码有意义吗？

Question

• 我指的是TDD意义上的单元测试。(不是自动化的“集成”，也不是您喜欢称之为测试的东西。)
• 遗留代码，如：(C++)没有测试的代码。(见:迈克尔·羽毛的有效地使用遗产代码)
• 但也包括遗留代码:我们的团队在过去10-5年中一直在使用的代码，因此我们经常很好地知道应该把东西放在哪里来改变一些东西。
• 我们已经对一些模块进行了单元测试(通过Boost.Test)，这些模块是后来出现的，或者是一个“自然”的单元测试(公共应用程序特定的容器、字符串、网络助手等等)。
• 我们还没有适当的自动验收测试。

现在，最近我有幸实现了3个面向用户的新特性。

我花了大约1-2个小时来完成我需要修改的代码部分，1-2小时来实现我需要修改的(小)代码，还有1-2个小时来确保应用程序在运行之后正常运行，它应该做的事情。

现在，我真的添加了一些代码。(我认为每个功能都有一种方法和几条调用线。)

排除这些代码(通过WEwLC中所建议的任何方法)，这样单元测试就会有意义(而不是一个完整的重言式)，如果不是更多的话，也很容易再花上2-4个小时。这将为每个功能增加50%-100%的时间，而不会立即受益，如

1. 我不需要单元测试来理解代码的任何内容。
2. 手工测试的工作量是相同的，因为我仍然需要测试代码是否正确地集成到应用程序的其余部分中。

当然，如果后来出现了“某人”并接触了该代码，理论上他可以从该单元测试中获得一些好处。(只有在理论上，因为经过测试的代码岛将生活在未经测试的代码的海洋中。)

因此，“这一次”我选择不做添加单元测试的艰苦工作:要正确(并且干净地)实现该特性，代码更改要比代码更改要复杂得多。

对于强耦合的遗留代码来说，这是典型的吗？我是不是懒惰/我们是否把优先次序作为一个团队设定错了？还是我是谨慎的，只测试开销不太高的东西？

Answer 1

你必须对这些情况持务实态度。每件事都必须有商业价值，但企业必须信任你来判断技术工作的价值。是的，拥有单元测试总是有好处的，但这种好处是否足以证明花费的时间是合理的呢？

我总是在新代码上争论，但是，对于遗留代码，你必须做出判断。

你经常在这个代码区工作吗？还有一个需要不断改进的理由。你在做重大的改变吗？还有一种情况是，它已经是新代码了。但是，如果你在一个复杂的领域做一个单行代码，而且可能在一年内不会再被触及，那么当然，重组的成本(更不用说风险)太高了。把你的一行代码放进去，快去冲个澡。

经验法则:总是对自己想，“我是否相信，我认为我应该做的这项技术工作，比他们要求的工作带来的好处更多？”

Answer 2

TDD意义上的单元测试的好处是获得一些独立的东西，而不需要一个稳定的团队多年来建立的口头传统。

这是一个很大的运气，同一个团队已经在同一个项目上了这么多时间。但这种情况最终会改变。人们会生病、无聊或升职。他们要么搬家，要么退休，要么死去。新的想法带来了新的想法，也有了改造学校学习方式的冲动。公司被出售和收购。管理政策发生变化。

如果你想让你的项目存活下来，你必须为改变做好准备。

Answer 3

编写单元测试是您的代码的未来校对。如果代码库没有测试，那么您应该为所有新特性添加新的测试，因为它使代码中的一部分更加健壮。

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