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

Question

有人要求我更新基于 Java 的旧应用程序，并与我开发的更多当前应用程序内联。

我们想介绍的其中一件事是针对任何新增强功能的测试驱动开发。

代码单元测试覆盖率目前很低<20%

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

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

所以重构如此低的单元测试覆盖率可能会引入问题，但要提高测试覆盖率你必须重构？!

尝试这样做时有没有办法降低风险？？

Answer 1

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

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

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

我过去这样做的方式是务实 - 最初似乎是无法克服的，但如果你经常并及时重复上述操作，你最终会得到代码，你不再“害怕”的。这需要时间，但可以做到。

我可以彻底推荐Michael Feather's Working with Legacy Code对于这类事情 - 它提供了许多实用的策略来处理您(我们都在某些时候经历过)所面临的问题