26、遗留代码的依赖移除与测试策略

遗留代码的依赖移除与测试策略

1. 工具选择

在接手遗留代码库时，工具的选择变得相对清晰。如果之前的开发者使用了某个工具且有可取之处，那么就继续使用该工具。例如，我们不想在添加代码覆盖率时，还要同时处理 RSpec 测试和现有的 Shoulda/Test::Unit 测试。

若代码库中还没有工厂工具，建议添加一个。因为为遗留应用编写测试时，可能需要创建完整的相关对象链，使用工厂工具一次性创建这些关联对象可以节省大量时间。

不过，这条规则也有例外：
- 原开发者选择的工具不适合支撑我们所需的测试。
- 现有的测试毫无用处，此时最好快速删除并重新开始，这样就能自由选择工具。有一个简单的规则可用于初步筛选遗留测试：如果在五分钟内无法弄清楚一个测试的作用，就删除它。

Rails 控制台在探索过程中是我们的好帮手，它能让我们快速尝试一些对象交互。当在控制台中弄清楚操作后，将命令转移到测试中，以便能重复运行。

2. 依赖移除的挑战

在遗留代码测试中，依赖是最具挑战性的问题。编写良好的测试驱动开发（TDD）代码的最大优点之一是，测试能迫使代码的各个部分尽可能相互独立。而没有测试的遗留代码往往高度相互依赖，这给添加测试带来了诸多困难：
- 测试单个方法可能需要创建多个对象。
- 如果一个功能单元难以触及或被封装在一个长达 300 行的方法中，就很难将测试限制在真正的功能单元上。

不过，我们可以采取一些方法，让需要测试的代码不再相互依赖，从而能够编写所需的测试。

3. 代码分离

让新代码不依赖于遗留代码的一个简单方法是自行分离代码。