假设我想在编写任何其他代码之前遵循纯TDD，即写单元测试。当我发现错误时，我必须编写单元测试来重现它，然后实现修复。
说我的应用程序中存在内存泄漏。我可以重现它 - 运行特定方法1,000,000,000次会导致OutOfMemoryException。此测试需要10秒才能失败。
长时间运行的单元测试通常不受欢迎，尤其是当它们消耗大量内存时。后来可能还有其他内存泄漏，因此这些测试的数量可能会增加。
那么如何修复这个错误的TDD-way？
答案 0 :(得分：7)
TDD要求您先编写测试，但这些测试不一定是单元测试。
单元测试并不总是最好的，有时甚至是可行的工具，用于测试所有行为或重现所有错误。例如，只有在多个线程上使用多个组件时才会暴露竞争条件。
在您的情况下，您有一个您知道有问题的特定方法，因此您可以编写单元测试来重现此错误，但这是一个合理的解决方案吗？你将解决这个问题，但在其他方法中没有类似的问题。你打算为每种方法写一个“不漏记忆”测试吗？
相反，我会尝试编写功能或集成测试，这些测试运行更完整的测试应用程序片段，并使用开发环境中可用的任何工具来尝试捕获内存泄漏。某些语言允许您执行代码，强制执行垃圾回收或其他清理，然后确认内存使用或已分配的对象计数已返回到先前的值。在其他可能不可行的环境中，您可能需要进行更广泛的测量，或许在性能测试部署中观察应用程序的内存使用情况。
单元测试很快（或者至少应该是这样）并且重点突出，因此当它们有意义时它们很好但最终你可以考虑可以收集的关于代码的各种测试或分析数据，以便成为TDD的一部分处理。如果您能够对应用程序的行为方式做出断言，即使是“内存使用应该随着时间的推移保持稳定”等广泛的陈述，开发可自动化的方法来测试这些断言并使用这些测试来推动您的设计然后我认为您是练习TDD。写出有意义的测试。
答案 1 :(得分：6)
编写一个测试，演示已使用的内存没有超过某个阈值，而不是实际上内存不足。