调试代码遗留_从遗留代码到可测试代码简介

调试代码遗留

“遗产”一词有很多含义。 主要是不好的。 我们似乎忘记了我们漂亮的代码在编写后三天就达到了“旧版”状态。 迈克尔·费瑟斯（Michael Feathers）在他的精彩著作“ 使用遗留代码有效地工作 ”中将遗留代码定义为没有测试的代码，这是有道理的，尽管花了我一段时间才能完全理解它。

没有测试的代码会腐烂。 它之所以腐烂，是因为我们对触摸它没有信心，我们害怕破坏“工作”部分。 代码腐烂意味着它不会改变，保持我们最初编写它的方式。 我将是第一个承认，每当我编写代码时，它都会以丑陋的形式出现。 在我写完它后，它可能看起来并不丑陋，但是如果我等了几天（或几个小时），我知道我会找到很多改进方法。 没有测试，我可以依靠重构工具的自动功能，也可以依靠纯粹的胆量（阅读：愚蠢）。

编写后，大多数代码看起来并不好看。 但是好无所谓。

因为代码很昂贵，所以我们希望它能帮助我们理解代码并最大程度地减少调试时间。 重构对于降低维护成本至关重要，因此测试是必不可少的。

这是您开始付款的地方

当然，问题在于为遗留代码编写测试很困难。 代码是混乱的，充满了近，远的依赖关系，没有适当的测试，修改代码的风险很大。 另一方面，遗留代码是最需要测试的代码。 它也是那里最常见的代码-大多数时候，我们不编写新代码，而是将其添加到现有代码库中。

在大多数情况下，我们将需要更改代码以对其进行测试。 以下是一些示例原因：

• 我们无法创建测试对象的实例。
• 我们不能将其与其依赖项脱钩
• 一次创建并影响不同方案的单例
• 未通过公共接口公开的算法
• 被测代码的基类中的依赖性。

一些工具（例如Java中的PowerMockito或C＃的Typemock Isolator）使我们能够绕开其中的一些问题，尽管它们也要付出代价：较低的速度和代码锁定。 较低的速度来自这些工具的工作方式，与其他模拟工具相比，它们的运行速度较慢。 代码锁定是额外耦合到已测试代码的副作用-我们使用电动工具的能力越多，他们对实现的了解就越多。 这导致测试和代码之间的耦合，因此使测试更加脆弱。 易碎的测试会带来较大的维护成本，因此人们尽量不要更改它们和代码。 尽管这看起来像是技术障碍，但它却表现出来，因此可以通过过程和领导力来克服（例如，一旦我们有了测试，就鼓励开发人员改进代码和测试）。

即使使用了电动工具，我们也需要做一些工作。 我们甚至可能需要做一些前期工作。 在我们编写测试之前，只要对测试的代码进行一些调整（只要它们没有风险即可）就可以简化测试。 除非代码是第一次编写起来简单易读。 是的，对。

我们需要执行以下操作：

• 公开界面
• 派生和实现类
• 更改可访问性
• 使用依赖注入
• 添加访问器
• 重命名
• 提取方法
• 提取类

对代码的某些更改正在其中引入“接缝”。 通过这些接缝，我们可以输入探针以检查代码更改的影响。 其他更改只是帮助我们理解了这一点。 无论这些东西是否在重构模式，我们都可以。 如果我们明智地应用它们，更重要的是安全地使用它们，我们可以更容易地准备要测试的代码并使测试更健壮。

在接下来的文章中，我将详细介绍这些内容。

翻译自: https://www.javacodegeeks.com/2014/10/from-legacy-code-to-testable-code-introduction.html

调试代码遗留