用自动化测试改造遗留代码的最佳实践

我将承担在相对较大和较旧的代码库中重新实现已经定义的接口（一组C ++头文件）的任务。在执行此操作之前，我希望具有尽可能完整的测试范围，以便我可以尽早，轻松地检测到重新实现错误。问题在于，已经存在的代码库没有被设计为易于测试的，具有（非常大的）类和函数，高度的耦合，具有（很多）副作用的函数等。

听说以前有类似任务的经验，以及如何将自动测试（单元，集成，回归等）改造为旧代码的一些好的具体建议，将是很高兴的。

首先，请阅读并阅读Michael Feathers的《有效地使用旧版代码》 -这是完成此类任务必不可少的帮助。

然后，请注意以下几点：

• 您对接口有精确的规范/合同，还是实际上仅将现有实现称为“规范”？在前一种情况下，更容易从头开始进行完全重写，而在后一种情况下，则很难甚至不可能。
• 如果您想重新实现该接口，则花费测试资源的最有用方法是仅针对该接口编写测试。当然，从严格意义上讲，这不符合单元测试的要求，而是功能/验收测试，但我不是纯粹主义者：-)但是，这些测试是可重用的，使您可以直接比较两个实现的结果。
• 总的来说，除非完全无法维护，我宁愿重构现有代码，而不是从头开始重写。（但是，在这种情况下，您将如何针对它编写单元测试？）请参阅Joel的这篇文章，以获取有关该主题的更详细的讨论。针对该接口创建了一组验收测试，可以为您提供一个薄而有用的安全网，您可以针对该安全网开始谨慎地重构现有代码，使其可以进行单元测试（使用Feathers的书中的想法）。

最好的方法是天皇方法。http://mikadomethod.wordpress.com/2010/08/04/the-mikado-method-book/ 这只是一种简单技术的概括，但这是我知道的开始在大型代码库中提高代码质量的唯一方法而不承担不必要的风险。

WEWLC也是一本很好的书，但是用C ++编写并不总是对Java或Ruby代码有用。

如果设计是整体的，则在旧代码库上进行复古拟合测试可能会非常困难。

如果可能的话（您有时间/金钱），一种前进的方法是将代码重构为更多可测试的单元。

我想添加一个链接。很少有没有那么容易测试的实现重构为更多xUnit友好代码的示例。至于一般方法，请尝试已经提到的链接（Joel post，使用旧版代码