unit-testing - 重构和测试驱动开发

Question

我目前正在阅读两本优秀的书籍“有效地使用遗留代码”和“清洁代码”。

他们让我思考我以全新的方式编写和使用代码的方式，但其中一个共同的主题是测试驱动开发，以及用测试扼杀一切并在开发之前进行测试的想法更改或实现一项新功能。

这导致了两个问题:

问题一: 如果我正在使用遗留代码。根据书籍，我应该进行测试以确保我没有破坏任何东西。假设我有一个 500 行长的方法。我会假设我将有一组等效的测试方法来测试该方法。当我拆分这个函数时，我是否为每个产生的新方法/类创建新测试？

根据“Clean Code”，任何超过 1/10 秒的测试都是耗时过长的测试。试图测试一个 500 长行的遗留方法，该方法进入数据库，上帝知道还有什么可能需要超过 1/10 秒的时间。虽然我知道您需要打破依赖关系，但我遇到的问题是初始测试创建。

问题二: 当代码被重构到结构上不再类似于原始代码时会发生什么(向方法添加/删除新参数等)。随之而来的是测试也需要重构？在那种情况下，您可能会在允许测试继续通过的同时改变系统的功能？在这种情况下重构测试是否合适？

虽然假设可以继续下去，但我想知道是否有集体经验对此类问题有任何想法/建议。

Answer 1

1. 在处理遗留代码时就是这样。遗留意味着没有测试并且紧密耦合的系统。为该代码添加测试时，您实际上是在添加集成测试。当您重构并添加更具体的测试方法来避免网络调用等时，这些就是您的单元测试。你想保留两者，然后分开，这样你的大部分单元测试都会运行得很快。
2. 您可以通过非常小的步骤来做到这一点。您实际上在测试和代码之间不断切换，您是正确的，如果您更改签名(小步骤)，则相关测试需要更新。

同时检查我在 How can I improve my junit tests 上的“更新 2” .它不是关于遗留代码和处理它已经存在的耦合，而是关于如何在涉及外部系统(即数据库、电子邮件等)的情况下编写逻辑 + 测试。