如何在不引入风险的情况下测试遗留应用程序(并采用测试驱动开发)？

Question

我被要求更新一个旧的基于java的应用程序，并与我工作过的更新的应用程序进行内联。

我们想要介绍的一件事是测试驱动开发，用于任何新的增强功能。

代码单元测试覆盖率目前非常低，<20%

作为应用程序的新手，我希望这个百分比要大得多，这样我就有信心在不引入缺陷的情况下进行更改。

问题是要提高这个百分比，很多代码都需要重新分解才能测试。

因此，使用如此低的单元测试覆盖率进行重构可能会带来问题，但为了提高测试覆盖率，您必须进行重构吗？！

在尝试这样做时，有什么方法可以降低风险吗？

Answer 1

低风险的方法是测试和重构是非常小的增量。在修改任何东西之前，你必须引入尽可能多的测试(并不总是那么容易)，然后继续这个过程，但要将重构纳入其中。

如果您保持最初的重构，将自包含的代码块提取到小的自包含方法中，那么风险很低(不是没有风险，但很低)，然后您可以尽可能地测试这两种原始方法，但还可以彻底测试提取的方法。

Mocking在这方面也有很大的帮助--你可以传入mock，而不是真正的服务，等等，这会有很大的帮助。你仍然会遇到麻烦的场景，代码在内部实例化/调用你不想测试的服务，但是随着时间的推移，你也可以通过引入依赖注入来解决这个问题(这样你就可以注入模拟而不是真正的服务)。但这可能是一个更长期的策略。

我过去这样做的方式是对它采取务实的态度--一开始似乎是无法克服的，但如果你经常重复上面的操作，你最终会得到你不再“害怕”的代码。这需要时间，但这是可以做到的。