我被要求更新一个旧的基于Java的应用程序，并与我目前使用的更多当前应用程序内联。
我们想要介绍的一件事是测试驱动开发，用于任何新的增强功能。
代码单元测试覆盖率目前非常低<20％
作为应用程序的新手，我希望这个百分比要大得多，让我有信心在不引入缺陷的情况下进行更改。
问题是如何提高这个百分比，很多代码都需要重新分解才能测试。
因此，如此低的单元测试覆盖率进行重新分解可能会引入问题，但为了获得测试覆盖率，您必须重新考虑因素？！
在尝试这样做的时候还有降低风险吗？
答案 0 :(得分：8)
低风险的方法是测试＆amp;重构是非常小的增量。你必须在修改任何东西之前引入尽可能多的测试（并不总是那么简单），然后继续这个过程，但是将refactorin包含在混合中。
如果你保持初始重构以将自包含的代码块提取到小的自包含方法中那么风险很低（不是没有风险，但是很低），然后你可以尽可能地测试原始方法，但另外彻底测试提取的方法。
Mocking也有很大帮助 - 你可以通过模拟而不是真正的服务等，这有助于提供很多帮助。您仍然会遇到麻烦的情况，其中代码在内部实例化/调用您不想测试的服务，但随着时间的推移，您还可以通过引入依赖注入来解决这个问题（这样您可以注入模拟而不是实际服务） 。但这可能是一个长期战略。
我过去做过这种方式的方式是务实 - 最初似乎是不可克服的，但如果你经常反复地做上述事情，你最终会得到代码，你不再“害怕”的。这需要时间，但可以做到。
我可以为这类事情彻底推荐Michael Feather's Working with Legacy Code - 它提供了很多实用的策略来处理你（我们都经历过，某些时候）遇到的问题