为什么要为将要重构的代码编写测试？

我正在重构一个巨大的遗留代码类。重构（我认为）主张：

1. 为遗留类编写测试
2. 摆脱困境

问题：一旦我重构了类，就需要更改步骤1中的测试。例如，以前是旧方法中的东西，现在可能是一个单独的类。一种方法现在可能是几种方法。遗留类的整个景观可能被抹杀为新的东西，因此我在步骤1中编写的测试几乎是无效的。本质上，我将添加步骤3。大量重写我的测试

那么重构之前编写测试的目的是什么？这听起来更像是为自己创造更多工作的学术活动。我现在正在为该方法编写测试，并且正在学习有关如何测试事物以及旧方法如何工作的更多信息。可以通过阅读旧代码本身来学习这一点，但是编写测试几乎就像在摸摸我的鼻子，并且在单独的测试中记录这种临时知识。因此，以这种方式，我几乎别无选择，只能学习代码在做什么。我在这里说的是暂时的，因为我会从代码中重构出乱七八糟的东西，并且我的所有文档和测试在很大程度上都是无效的，除非我的知识会留下来并使我对重构更加新鲜。

这是重构之前编写测试的真正原因-帮助我更好地理解代码吗？还有另一个原因！

请解释！

注意：

有一篇文章：没有时间进行完全重构时，为遗留代码编写测试是否有意义？但是它说“重构之前先写测试”，但没有说“为什么”，或者说“写测试”看起来像“很快就会被销毁的繁忙工作”该怎么办。

重构就是在不更改（外部可见）行为的情况下清理一段代码（例如，改进样式，设计或算法）。你写测试不确保前和重构后的代码是一样的，而不是你写测试作为一个指标，之前和之后重构你的应用程序的行为是一样的：新的代码兼容，并且没有引入新的错误。

您主要关心的是为软件的公共接口编写单元测试。该界面不应更改，因此测试（对此界面的自动检查）也不应更改。

但是，测试对于定位错误也很有用，因此也可以为软件的私有部分编写测试。这些测试预计将在整个重构过程中发生变化。如果要更改实现细节（例如私有函数的命名），则首先更新测试以反映更改后的期望，然后确保测试失败（您的期望未得到满足），然后更改实际代码并检查所有测试是否再次通过。公用接口的测试决不应开始失败。

当进行较大的更改（例如重新设计多个相互依赖的零件）时，这将更加困难。但是会有某种界限，在那个界限上，您将能够编写测试。

嗯，维护旧系统。

理想情况下，您的测试仅通过类与其他代码库，其他系统和/或用户界面的接口来处理该类。接口。您不能在不影响那些上游或下游组件的情况下重构接口。如果全部都是紧密耦合的混乱，那么您最好将其视为重写而不是重构，但这主要是语义上的。

编辑： 假设您的代码的一部分可以测量某些东西，并且它具有仅返回值的函数。唯一的接口是调用函数/方法/ Whatnot并接收返回的值。这是松耦合，易于单元测试。如果您的主程序有一个管理缓冲区的子组件，并且对它的所有调用都取决于缓冲区本身，一些控制变量，并且它通过另一部分代码消除了错误消息，那么您可以说这是紧密耦合的，并且很难进行单元测试。您仍然可以使用足够数量的模拟对象来执行此操作，但是会变得混乱。特别是在c。重构缓冲区如何工作的任何数量都会破坏子组件。
结束编辑

如果您通过保持稳定的接口来测试您的类，那么您的测试在重构前后应该是有效的。这使您可以自信地进行更改，而不会破坏它。至少，更有信心。

它还允许您进行增量更改。如果这是一个很大的项目，我认为您不会想要将其全部拆掉，构建一个全新的系统，然后开始开发测试。您可以更改它的一部分，进行测试，并确保所做的更改不会降低系统的其余部分。或者，如果这样，您至少可以看到巨大的纠结的混乱正在发展，而不是在释放时感到惊讶。

尽管您可以将一个方法拆分为三个，但是它们仍然会做与前一个方法相同的操作，因此您可以对旧方法进行测试，然后将其拆分为三个。编写第一项测试的工作不会浪费。

同样，将遗留系统的知识视为“临时知识”也不会很顺利。当涉及到遗留系统时，了解它以前是如何做的至关重要。对于“为什么会那样做？”这个古老的问题非常有用。

我自己的答案/实现：

通过在重构时修复各种错误，我意识到，如果没有测试，我将不会轻易完成代码移动。测试使我意识到通过更改代码而引入的行为/功能“差异”。

当您进行了良好的测试时，您不必非常了解。您可以以更轻松的举止来编辑代码。测试会为您进行验证和健全性检查。

另外，我的测试与重构后的测试几乎一样，没有被破坏。实际上，当我深入研究代码时，我已经注意到了一些额外的机会来将断言添加到测试中。

更新

好吧，现在我要大量更改测试：/因为我重构了原始函数（删除了该函数，而是创建了一个新的cleaner类，将原来位于函数内部的绒毛移到了新类之外），所以现在我之前运行的被测代码使用不同的类名输入不同的参数，并产生不同的结果（带有绒毛的原始代码具有更多要测试的结果）。因此，我的测试需要反映这些变化，并且基本上，我正在将测试重写为新的东西。

我想还有其他解决方案可以避免重写测试。例如，用新代码保留旧函数名称，并在其中包含绒毛...但是我不知道这是否是最好的主意，我还没有足够的经验来判断该怎么做。

使用测试来驱动代码。在旧版代码中，这意味着为要更改的代码编写测试。这样，它们就不是单独的工件。测试应该是关于代码需要实现的内容，而不是关于代码如何实现的内在胆量。

通常，您要在没有代码的代码上添加测试）以重构代码，以确保代码行为继续按预期运行。因此，在重构时连续运行测试套件是一个了不起的安全网。没有测试套件来更改代码以确认更改不会影响未预料到的事情的想法令人恐惧。

至于更新旧的测试，编写新的测试，删除旧的测试等的艰辛，我只是将其视为现代专业软件开发成本的一部分。

在您的特定情况下重构的目标是什么？

出于对我的回答的推定，我们都（一定程度上）相信TDD（测试驱动开发）。

如果重构的目的是在不更改现有行为的情况下清理现有代码，那么在重构之前编写测试就是确保未更改代码行为的方式，如果成功，则测试前后都会成功你重构。

• 这些测试将帮助您确保您的新作品切实可行。

• 测试可能还会发现原始作品无效的情况。

但是，您如何真正进行任何重要的重构而又不会在某种程度上影响行为？

以下是重构期间可能发生的一些事情的简短列表：

• 重命名变量
• 重命名功能
• 增加功能
• 删除功能
• 将功能分为两个或多个功能
• 将两个或多个功能合并为一个功能
• 分组课
• 结合类
• 重命名课程

我要争辩说，列出的活动中的每一项都会以某种方式改变行为。

我要争论的是，如果您的重构改变了行为，那么您的测试仍然将是确保您没有破坏任何东西的方式。

也许行为不会在宏级别上发生变化，但是单元测试的目的并不是要确保宏行为。那就是集成测试。单元测试的重点是确保构建产品时所用的零碎零碎。链，最薄弱的环节等

这种情况如何：

• 假设你有 function bar()

• function foo() 打电话给 bar()

• function flee() 也打电话给函数 bar()

• 仅出于多样性，flam()请致电foo()

• 一切工作出色（显然，至少）。

• 您重构...

• bar() 被重命名为 barista()

• flee() 改为通话 barista()

• foo()是不是改叫barista()

显然，你的这两个测试foo()和flam()现在失败。

也许您一开始就没有意识到foo()打来电话bar()。你肯定不知道，flam()是依赖于bar()通过的方式foo()。

随你。问题的关键是，你的测试将揭示两者的新破碎行为foo()和flam()，你的重构工作中以增量方式。

这些测试最终可以帮助您良好地重构。

除非您没有任何测试。

这是一个人为的例子。有些人会认为，如果更改bar()中断了foo()，那么foo()从一开始就太复杂了，应该将其分解。但是过程由于某种原因能够调用其他过程，因此不可能消除所有复杂性，对吗？我们的工作是合理地管理复杂性。

考虑另一种情况。

您正在建造建筑物。

您建立一个脚手架，以帮助确保正确地建造建筑物。

脚手架可帮助您构建电梯井等。之后，您拆除了脚手架，但电梯井道仍然存在。您通过破坏脚手架破坏了“原始工作”。

这个类比是脆弱的，但重点是构建帮助您构建产品的工具并非闻所未闻。即使这些工具不是永久性的，它们也很有用（甚至是必要的）。木匠一直在做夹具，有时只做一份工作。然后，他们将夹具拆开，有时使用零件为其他工作制造其他夹具，有时不使用。但这并不会使夹具变得毫无用处或浪费。