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 ? .. [1] http://osdir.com/ml/python-dev/2013-10/msg00109.html .. [2] http://www.python.org/dev/peps/pep-0454/ -- Regards, Olemis - @olemislc
