我已经开始了我在重构巨系统和为它编写单元测试的第一次经验，但是我害怕我不知道它会破坏代码。 我研究了“单元测试的艺术”和“使用遗留代码高效工作”来寻找解决方案，我的下一个计划是停止一段时间的重构并编写一些集成测试（我选择了Fitnesse工具进行集成测试）在我改变一些东西后每次运行它们。 我只是想知道有没有其他人有相同的经验？你认为整合测试可以解决这个问题吗？你有更好的主意吗？我如何知道我在重构期间没有破坏任何东西？
我也检查了这个问题（How can I check that I didn't break anything when refactoring?）但我的情况是不同的，因为没有单元测试可用，我在这里写单元测试。
在一天结束时，这是使用遗留代码的问题。
集成测试是您最好的选择，但为了正确地满足您的需求，您需要知道原始代码的原始意图，而原始代码通常不太清晰，因为通常存在隐藏需求。
没有理想的解决方案。
我正在处理一个没有任何文档的大系统，只能访问长期开发系统并仍然维护它的程序员。我最近加入了团队，帮助他们重构系统并使其可测试，但我害怕破坏某些东西，因此我决定编写集成和验收测试来覆盖整个系统，然后开始重构。我为此选择了FitNesse，但我现在还不确定，您对这些工具有什么想法？ – Fery 2014-10-15 23:03:38
集成测试是重构良好解决方案的一部分。但是，重构时引入的一些问题只会在您部署项目时才显示出来。
一个更好的想法是将集成测试纳入策略中。这意味着您应该有一个干净而实用的方法，在重构它的同时尽可能多地构建和部署项目到几乎相同的环境。这本书Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment是一个很好的资源。下面是它描述了反模式（7-9页）中的一个：
反模式：部署到生产环境中开发完成
在此模式中，第一次的软件只有在一旦应用程序部署到分期部署到 生产环境中（例如，分期）是最多一次的 的开发工作完成后...
，这是很常见的发现新 错误...
补救措施是将测试，部署和发布活动集成到开发过程中。使它们成为正常开发的一部分，以便当您准备好将您的系统投入生产时，几乎没有风险，因为您已经在许多不同的场合排练了它，并且逐渐产生了更多的生产状态测试环境的序列。使 确保大家参与到软件交付流程中，从 构建和发布团队到测试人员到开发人员，共同从 开始项目。
我正在处理一个没有任何文档的大系统，只能访问长期开发系统并仍然维护它的程序员。我最近加入了团队，帮助他们重构系统并使其可测试，但我害怕破坏某些东西，因此我决定编写集成和验收测试来覆盖整个系统，然后开始重构。我为此选择了FitNesse，但我现在还不确定，您对这些工具有什么想法？ – Fery 2014-10-15 23:01:21
虽然以前的答案非常好，但我想补充一点，单元测试正是为了这个。在我们的测试项目中，当我们重构每个其他组件时，它必须运行已经存在的从初始开发人员+新版本准备的单元测试，然后将版本控制提交到。此外 - 它是一个很好的方法，可以让每个登机手续都运行smoke。之后的课程 - 综合，回归等。
UPDATE
我在完全相同的情况是 - 链接到维护。工具可能会有很大不同 - 取决于需求。从Web-，-Unit-Testing开始，直到SOA和服务器测试。如果您提供有关您的SUT的更详细信息，我会很乐意帮助您。
我正在处理一个没有任何文档的大系统，只能访问长期开发系统并仍然维护它的程序员。我最近加入了团队，帮助他们重构系统并使其可测试，但我害怕破坏某些东西，因此我决定编写集成和验收测试来覆盖整个系统，然后开始重构。我为此选择了FitNesse，但我现在还不确定，您对这些工具有什么想法？ – Fery 2014-10-15 23:03:04
老实说，您需要的所有答案都在您引用的其中一本书中，与遗留代码一起高效工作。第16章：我不了解代码足以改变这可能是一个好的开始。更具针对性的是你的具体问题是第23章：我怎么知道我没有打破任何东西？ – 2014-10-10 16:22:17
我正在处理一个没有任何文档的大系统，只能访问长期开发系统并仍然维护它的程序员。我最近加入了团队，帮助他们重构系统并使其可测试，但我害怕破坏某些东西，因此我决定编写集成和验收测试来覆盖整个系统，然后开始重构。我为此选择了FitNesse，但我现在还不确定，您对这些工具有什么想法？ – Fery 2014-10-15 23:01:46