On 15/04/2011 17:49, Martin (gzlist) wrote:
On 14/04/2011, Michael Foord<fuzzy...@voidspace.org.uk> wrote:
I'd be interested to know what is keeping the tests alive even when the
test suite isn't. As far as I know there is nothing else in unittest
that would do that.
The main cause is some handy code for collecting and filtering tests
by name, which unintentionally keeps alive a list outside the
TestSuite instance.
There's also the problem of reference cycles involving exc_info, bound
methods, and so on that make the lifetimes of test cases
unpredictable. That's mostly a problem for systems with a very limited
allotment of certain resources such as socket handles. However it also
makes ensuring the code doesn't regress back to leaking-the-universe
more complicated as tests may still survive past the pop.
It's either a general problem that unittest can fix, or it is a problem
*caused* by the bazaar test suite and should be fixed there. Bazaar does
some funky stuff copying tests to run them with different backends, so
it is possible that this is the cause of the problem (and it isn't a
general problem).
The fact it's easy to accidentally keep objects alive is a general
problem. If every project that writes their own little test loader
risks reverting to immortal cases, that's not really progress. The
Bazaar example is a warning because the intention was the same as
yours, but ended up being a behaviour regression that went unnoticed
by most of the developers while crippling others. And as John
mentioned, the fix hasn't yet landed, mostly because the hack is good
enough for me and the right thing is too complicated.
I can't remember if I replied to this or not. Sorry.
Anyway, so long as *unittest* doesn't keep your test cases alive (which
currently it does) then if any individual test framework keeps the tests
alive that is a bug in the framework (and it can be tested for).
If we stomp on the test instance dictionaries then legitimate use cases
may be prevented (like test cases copying themselves and executing a
copy when run - a use case described by Robert Collins in a previous email).
Although other test frameworks may implement additional measures
required specifically by them, the duty of unittest is just to ensure
that it doesn't make disposing of test cases *impossible* during normal use.
All the best,
Michael Foord
Martin
--
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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
