【发布时间】：2011-03-13 08:47:17
【问题描述】：
情况：数百万行代码，一百多名开发人员，缺陷频发。我们希望避免重复缺陷，并且我们希望改进代码设计（谁不呢？）。
测试驱动开发（首先是单元测试，然后是代码）听起来很理想：为每个函数编写一个测试用例。
但是，编写了这么多代码，如何实现 TDD？你从哪里开始 - 从低级功能开始？
还是我们开始 TDD 太晚了？
【问题讨论】：
标签： unit-testing testing legacy-code tdd
【发布时间】：2011-03-13 08:47:17
【问题描述】：
既然 Carl 推荐了一本书，我将推荐另一本书：Roy Osherove 的 Art of Unit Testing 有一整章是关于“使用遗留代码”的。那一章我还没看，不过前5章很不错，很期待。
【讨论】：
-
仅供参考，我喜欢 Osherove 对遗留代码定义的比较：“与不再受支持的技术相关的源代码”“正在维护的任何旧应用程序”“有效的代码”“没有测试的代码"（摘自 Feathers 的书）
-
@Orbfish - 感谢您的提示。也许当你读过它时，你会回来分享一些见解？
以Working Effectively with Legacy Code开头。
如果您从遗留代码开始，这并不是真正的 TDD - 但您的所有编码都可以是 TDD。当你解决一个新问题时，为它写一个测试。如果你不能，因为遗留类太难测试，那就开始为它们编写测试，切掉一些位，并用测试覆盖这些位。
Refactor the Low-Hanging Fruit.
为避免重复缺陷：给定一个示例缺陷，编写一个测试来演示它。这可能是一个相对广泛的测试，仅模拟用户活动；还不是单元测试。确保测试失败。做你的研究；找出测试失败的原因。现在 - 这很重要 - 在修复错误之前，编写一个演示错误的单元测试。修复错误，现在您有两个测试，其中至少一个快速，可以保护您免受回归。
【讨论】：
-
+1：这里的关键是不尝试全面改进单元测试。
-
@Carl - 很好的总结。我特别喜欢你如何从缺陷中获得单元测试和系统文本。
-
@Richard - 我很困惑 - 这不是和 Carl 所说的相反吗？
-
@Mark，我认为 Richard 和我同意；关键是“全面”。如果您浏览遗留代码库并在继续前进之前尝试涵盖所有内容，那么您最终会一事无成（并且没有任何东西可以展示）。只处理您需要处理的部分；随着时间的推移，您的系统经过了相当良好的测试，并且在此过程中，您正在添加功能（或至少消除错误）。
-
@Gutzofter - 当然，否则您只需将测试添加到遗留代码......然后您的新代码很快就会变成遗留代码！ :)