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