On Fri, Nov 1, 2013 at 11:23 AM, Olemis Lang <[email protected]> wrote:
> On Thu, Oct 31, 2013 at 12:53 PM, Ryan Ollos <[email protected] > >wrote: > > > On Thu, Oct 31, 2013 at 12:15 AM, <[email protected]> wrote: > > > > > > > [...] > > > > > In the tearDown function of many TestCases I see the following: > > > > self.env = self.global_env = None > > > > In most cases it is the last line of code in the tearDown method. > > > > Does anyone know the purpose of this? > > > Release memory associated to transient objects allocated by the test case > instance . > > See this message [1]_ sent to python-dev for further comments about related > optimizations performed to stdlib test suite thanks to Victor Stinner > pushing for tracemalloc module [2]_ > > The test fixture will be created for > > each method that is executed, so I can't see a reason for needing to > > perform any reset on the attributes. > > > > ... but you'll still keep a reference to the objetcs , and internally > unittest module keeps references to TC instances . > > By not doing so if the test suite has 1k test cases then there will be > 1k > EnvironmentStub objects hanging around without any good reason (afaict) . > The functional test suite is a bit different because it's possible to > perform post-mortem analyzes by reviewing file-system and DB contents > related to the target BH test environment . > > If you'd run the test suite on hosted Jenkins instances then you'll > definitely want to save some dynos, k-pax or whatever other name is used to > track resource usage and apply quotas > ;) > > > > The reason I care about this is that I'm working on adding a > > cleanup method (via TestCase.addCleanup) to > > bloodhound_multiproduct.tests.env:MultiproductTestCase._setup_test_env > that > > removes the temporary environment directories after the test run > completes. > > env.path is needed, and if env is set to None in the tearDown method, > then > > the cleanup function will throw an exception. > > > > I've recently seen a changeset about that ... [r1537391] ? ... well, if you > want to add such a function then ensure that memory for those (useless) > objects is also released afterwards . Does it makes any sense , or is there > any other major objection ? > Thank you for the explanation. I will try moving "release of objects" from the tearDown methods into the proposed _teardown_test_env "cleanup" function. I think it will look something like this, def _teardown_test_env(self): if env.path: shutil.rmtree(env.path) self.env = None if self.prod_env: self.global_env = None
