Unit testing 遵循TDD时如何处理内存泄漏

假设我想遵循纯TDD，即在编写任何其他代码之前编写单元测试。当我发现一个bug时，我必须编写单元测试来复制它，然后实施修复

假设我的应用程序内存泄漏。我可以复制它-运行特定方法100000000次会导致OutOfMemoryException。此测试需要10秒钟才能失败

长时间运行的单元测试通常不受欢迎，尤其是当它们消耗大量内存时。此外，稍后可能会出现其他内存泄漏，因此此类测试的数量可能会增加

---

那么，如何用TDD方法修复这个错误呢？

编写一个测试，证明使用的内存没有超过某个阈值，并不是说内存实际用完了。

TDD要求您首先编写测试，但这些测试不一定是单元测试

单元测试并不总是测试所有行为或复制所有bug的最佳工具，有时甚至不是可行的工具。例如，只有在多个线程上使用多个组件时，才可能暴露争用条件

在您的案例中，您知道有一种特定的方法存在问题，所以您可能能够编写一个单元测试来重现这个bug，但这是一个合理的解决方案吗？您将修复这一个问题，但在其他方法中不会修复类似的问题。您是否要为每个方法编写一个“不泄漏内存”测试

相反，我会尝试编写功能测试或集成测试，运行被测应用程序的更完整部分，并使用开发环境中可用的任何工具来捕获内存泄漏。某些语言允许您执行代码、强制垃圾收集或其他清理，然后确认内存使用或分配的对象计数已返回到以前的值。在其他可能不可行的环境中，您可能需要进行更广泛的测量，可能需要在性能测试部署中观察应用程序的内存使用情况

---

单元测试是快速的（或至少它们应该是）并且集中在它们有意义的时候它们是好的，但是最终你可以考虑你可以收集的关于代码的每一种测试或分析数据作为TDD过程的一部分。如果您能够对应用程序的行为做出断言，即使是“内存使用应随时间保持稳定”之类的广泛声明，也可以开发自动化的方法来测试这些断言，并使用这些测试来驱动您的设计，那么我认为您在实践TDD。写一些有意义的测试。

+1关于这种类型的错误不必由单元测试来处理的论点。使用Delphi，您可以使用FastMM来检测内存泄漏。当然，您的编程环境也有类似的检测工具，请使用它们。