[Python-Dev] Test cases not garbage collected after run

Michael Foord fuzzyman at voidspace.org.uk
Fri Apr 8 12:38:53 CEST 2011


On 08/04/2011 02:10, Robert Collins wrote:
> On Fri, Apr 8, 2011 at 8:12 AM, Michael Foord<fuzzyman at voidspace.org.uk>  wrote:
>> On 07/04/2011 20:18, Robert Collins wrote:
>>> On Fri, Apr 8, 2011 at 4:49 AM, Michael Foord<fuzzyman at voidspace.org.uk>
>>>   wrote:
>>>> You mean that the test run keeps the test instances alive for the whole
>>>> test
>>>> run so instance attributes are also kept alive. How would you solve this
>>>> -
>>>> by having calling a TestSuite (which is how a test run is executed)
>>>> remove
>>>> members from themselves after each test execution? (Any failure
>>>> tracebacks
>>>> etc stored by the TestResult would also have to not keep the test alive.)
>>>>
>>>> My only concern would be backwards compatibility due to the change in
>>>> behaviour.
>>> An alternative is in TestCase.run() / TestCase.__call__(), make a copy
>>> and immediately delegate to it; that leaves the original untouched,
>>> permitting run-in-a-loop style helpers to still work.
>>>
>>> Testtools did something to address this problem, but I forget what it
>>> was offhand.
>>>
>> That doesn't sound like a general solution as not everything is copyable and
>> I don't think we should make that a requirement of tests.
>>
>> The proposed "fix" is to make test suite runs destructive, either replacing
>> TestCase instances with None or pop'ing tests after they are run (the latter
>> being what twisted Trial does). run-in-a-loop helpers could still repeatedly
>> iterate over suites, just not call the suite.
> Thats quite expensive - repeating discovery etc from scratch.

Nope, just executing the tests by iterating over the suite and calling 
them individually - no need to repeat discovery. With the fix in place 
executing tests by calling the suite would be destructive, but iterating 
over the suite wouldn't be destructive - so the contained tests can 
still be executed repeatedly by copying and executing.
>   If you
> don't repeat discovery then you're assuming copyability.
Well, individual test frameworks are free to assume what they want. My 
point is that frameworks that wish to do that would still be able to do 
this, but they'd have to iterate over the suite themselves rather than 
calling it directly.
> What I
> suggested didn't /require/ copying - it delegates it to the test, an
> uncopyable test would simply not do this.
>
Ok, so you're not suggesting tests copy themselves by default? In which 
case I don't see that you're offering a fix for the problem. (Or at 
least not a built-in one.)

All the best,

Michael Foord

> -Rob


-- 
http://www.voidspace.org.uk/

May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html



More information about the Python-Dev mailing list