【发布时间】：2010-11-23 14:11:06
【问题描述】：
我们的团队正计划在遗留代码库中重构一些模块。它是一个用 java 编写的 Web 应用程序。它根本没有单元测试。
我要求开发人员在重构之前为现有功能编写一个junit，但我相信这不会很广泛。
我可以采取哪些其他措施（黑盒/白盒/进程）来确保重构不会干扰任何现有功能。
目前的系统相当稳定，已经运行了8年多。
谢谢 灰色
【问题讨论】：
标签： refactoring qa
【发布时间】：2010-11-23 14:11:06
【问题描述】：
在开始之前阅读 Michael Feathers 的 Working Effectively with Legacy Code。
当前状态下的代码很可能无法进行有效的单元测试（因为它可能不在单元中）。我所看到的运行良好的是集成级测试，它只需使用一些合理的输入运行并记录输出； Web 应用程序使这一点特别合适。编写这些，然后产生一些小方法和类——对所有新事物进行单元测试——同时保持这些高级测试正常工作。这比从一开始就正确执行 TDD 需要更多的工作，但它绝对是可行的。
【讨论】：
-
这是一本很棒的书，让我对代码维护有了全新的（更乐观的）观点。
-
感谢您推荐这本书。我正在浏览它并发现它很有用。我已要求开发人员编写测试然后对其进行修改。但是考虑到时间/预算限制，在遵循 Stirct TDD 方面会有一些妥协。
您可能会面临 2 个问题：代码在现代意义上不可单元测试，并且代码中存在尚未发现的错误。面对这种情况，我强烈建议您尽可能多地使用黑白盒测试。我理解，这是一个痛苦的过程，但有办法缓解它。
您的工程师能否分解出一些接口，以便您可以创建一些集成测试。也就是说，如果他们进行重构，他们能否围绕一些共同领域巩固并将应用程序划分为更小的块，这些块在可预见的未来将在开发周期中基本保持不变？这将允许您至少有一些更大的方法来执行更多测试。它还允许您，质量检查人员，询问现有代码的预期结果。
【讨论】：
-
你是对的。大多数代码不是可单元测试的。一些重构主要是删除未使用的变量和方法，并将重复的代码放入通用方法中。我们通过工具确保方法和变量真正未被使用并且是的，在无法进行单元测试的情况下使用黑盒测试来覆盖
-
@Jenga Blocks 小心点。有时遗留代码往往会在错误的地方进行“错误修复”。可能在一个地方找到与另一个地方的错误逻辑直接相关的逻辑。通过修复一个错误，您可能会在另一个中引入错误。
除了写更多的junit，你总是可以record test scripts with JMeter. 包含断言以确保您获得预期的结果。
【讨论】：
-
嘿，这是个好主意。但是项目已经转移了很多，我不能投资于当前的发布。不过，我可以在未来的重构计划中使用这种方法。谢谢。