[issue5679] cleanUp stack for unittest
Changes by Kumar McMillan kumar.mcmil...@gmail.com: -- nosy: +kumar303 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5679 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5679] cleanUp stack for unittest
Kumar McMillan kumar.mcmil...@gmail.com added the comment: I like this patch. However, a nice-to-have would be that _doCleanups() prints a traceback from function(*args, **kwargs) (if there is one) the same way that atexit does. That would aid in debugging mis-written cleanup functions yet would not intrude on your test program. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5679 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5538] tearDown in unittest should be executed regardless of result in setUp
Kumar McMillan kumar.mcmil...@gmail.com added the comment: fwiw, changing tearDown() so that it executes unconditionally will break a countless number of test suites. No test suite since the dawn of unittest has been designed to tearDown() what may not have been setUp() correctly. in other words, this is how [in my experience] setUp and tearDown are typically used together. Imageine this error in setUp() : def setUp(self): self.tmp_io = TempIO() # raise NameError(no such name TempIO) self.db = DataBase() def tearDown(self): self.tmp_io.destroy() self.db.destroy() With the change, you would need messy code like: def tearDown(self): if hasattr(self, 'tmp_io'): self.tmp_io.destroy() if hasattar(self, 'db'): self.db.destroy() This is just a simple example; things would get complicated fast. I think addCleanup() is a good idea though. Or what about a new hook that would act like tearDown() but execute unconditionally. alwaysTearDown() ? (I'm bad with names.) Using a different hook would solve the problem of porting test suites to this new paradigm. But besides that there are alternatives for doing cleanup. I.E. if setUp() in a class fails, then teardown_module() will still be called. -- nosy: +kumar303 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5538 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5538] tearDown in unittest should be executed regardless of result in setUp
Kumar McMillan kumar.mcmil...@gmail.com added the comment: For the record, I too have been plagued by failing setUp's :( and the pattern you describe is not uncommon. I was just pointing out that changing the semantics of tearDown() will affect a lot of existing code. As with any backwards incompatible change the effort of porting to the new functionality should be considered. In this case my fear is that it will be hard to know that tearDown() is not behaving how it used to behave since an exception in tearDown() would be once removed from the actual exception in setUp(). More directly addressing your problem, have you considered switching to context managers? Could maybe do something like: with ConfiguredIOS(): test_something() the context manager could define __exit__() which would get called unconditionally. Also, these could be chained together as decorators to sort-of do what it seems like you were trying to do in tearDown(). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5538 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4554] Missing make altframeworkinstall for Mac OS X
Changes by Kumar McMillan [EMAIL PROTECTED]: -- nosy: +kumar303 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4554 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
