我如何知道在重构期间我没有破坏任何东西？

Question

我已经开始了第一次重构庞大系统并为其编写单元测试的经验，但我只是害怕我在不知情的情况下打破了代码。 我研究了“单元测试的艺术”和“使用遗留代码有效地工作”来找到解决方案，我的下一个计划是停止重构一段时间并编写一些集成测试（我选择Fitnesse工具进行集成测试）我改变一些东西后每次运行它们。 我只是想知道是否有其他人有相同的经历？您是否认为合并测试可以很好地解决这个问题？你有更好的主意吗？

我也检查了这个问题（How can I check that I didn't break anything when refactoring?），但我的情况与此不同，因为没有可用的单元测试，我在这里编写单元测试。

Answer 1

集成测试是重构的良好解决方案的一部分。但是，重构引入的一些问题只会在您部署项目时出现。

更好的想法是将集成测试纳入 continuous delivery 策略。这意味着您应该有一个干净实用的方法来尽可能多地构建和部署项目，同时重构它。书Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment是一本很好的资源。这是它描述的反模式之一（第7-9页）：

  

反模式：仅在开发完成后部署到类似生产的环境

     

在此模式中，第一次将软件部署到a   像生产一样的环境（例如，分期）曾经是大部分时间   开发工作已经完成......

     

将应用程序部署到临时表后，新的常见问题   找到错误......

     

补救措施是集成测试，部署和发布   活动进入发展过程。让他们成为正常的   持续的发展部分，以便在你准备好的时候   将您的系统投入生产中几乎没有风险，   因为你已经在很多不同的场合排练了它   逐渐增加类似生产的测试环境序列。使   确保每个人都参与软件交付过程   构建和发布团队，以测试人员与开发人员一起工作   项目的开始。

Answer 2

在一天结束时，这是使用旧版代码的问题。

集成测试是您最好的选择，但要编写正确满足您需求的测试，您需要知道原始代码的原始意图，这通常不太明确，因为通常存在隐藏的需求。

没有理想的解决方案。

Answer 3

虽然以前的答案非常好，但我想补充一点，单元测试正是为了这个。在我们的测试项目中，当我们重构其他组件时，它必须运行已经从初始开发人员+新提交提交之前到Version控件的现有单元测试。此外 - 它是在每次签到时运行 smoke 测试的好方法。一个过程 - 后来的整合，回归等。

更新

我处于完全相同的情况 - 被束缚于维护。工具可以根据需要变化很大。从Web，-Unit-Testing开始，直到SOA和服务器测试。如果您提供有关SUT的更详细信息，我很乐意帮助您。