【问题标题】:Temporary object-pool for unit tests?单元测试的临时对象池?
【发布时间】:2017-06-06 13:50:17
【问题描述】:

我正在为一个复杂的项目运行一个大型单元测试存储库。 这个项目有一些东西不能很好地处理大量的测试:

  1. 导致对象在测试之间不被释放的缓存(记忆)
  2. 模块级别的复杂对象是单例并且在使用时可能会收集数据

我对每个测试(或至少每个测试套件)都有自己的“python-object-pool”并能够在之后释放它感兴趣。

某种 python-garbage-collector-problem 解决方法。

我想象一个 python 独立的临时和可丢弃的解释器,它可以为我运行某些代码,并且在我可以调用“interpreter.free()”并确保它不会泄漏之后。

我发现一个艰难的解决方案是每次我需要一个可以运行测试的消耗性解释器时使用 Nose 或通过子进程实现它。所以每个测试都变成了“fork_and_run(conditions)”,并且在原始进程中不泄漏任何内存。

还看到每个测试的 Nose 单个进程并按顺序运行测试 - 尽管人们提到它有时会在中途冻结 - 不那么有趣..

有没有更简单的解决方案?

附: 我对浏览大量其他人的代码并试图使他们所有的缓存/对象/项目成为可以清理的完美内存管理对象不感兴趣。

P.P.S 我们的 PROD 代码还为每项工作创建了一个新流程,这非常舒适,因为我们不必纠结于“永远生存”和其他可怕的故事。

【问题讨论】:

    标签: python unit-testing memory-management garbage-collection virtualization


    【解决方案1】:

    TL;DR 我尝试在本地工作的模块重新加载技巧,在具有不同 python 版本的机器上使用时崩溃了......(?!)

    我最终获取了我在代码中编写的所有缓存并将它们添加到全局缓存列表中 - 然后在测试之间清除它们。 遗憾的是,如果有人使用缓存/手动缓存机制并错过了这一点,这将中断,测试将再次开始在内存中增长......

    对于初学者,我编写了一个循环,遍历 sys.modules 字典并重新加载(循环两次)我的代码的所有模块。这非常有效——所有引用都被正确释放,但由于多种原因,它似乎不能用于生产/严重代码:

    1. 旧的 python 版本在重新加载时会中断,并且继承元类的类被重新定义(我仍然不明白这是如何中断的)。
    2. 单元测试在重新加载后仍然存在,并且有时对旧类有错误的实例 - 特别是如果该类使用另一个类实例。想想 super(class_name, self),其中 self 是之前定义的类,现在 class_name 是重新定义的同名类。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2017-07-15
      • 2017-12-11
      • 2011-09-26
      • 2021-11-06
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多