So I was looking at zope.testing.loggingsupport as a way to replace CMFCore.tests.base.testcase.LogInterceptor, which exists for a similar purpose. Duplication is bad and all that.
The thing that struck me about loggingsupport.InstalledHandler is that you really want to create one during setUp() and "uninstall" it during tearDown(); otherwise if a test fails the handler will stay active for the rest of the test run and you could end up with a whole bunch of them. (Maybe that's harmless.) The one thing that struck me is that unlike the old zLOG-based LogInterceptor, there's no easy way to disable other handlers. e.g. I typically don't want to see expected log spew on stdout when running tests, it's distracting. LogInterceptor did that, true to its name it swallowed all logging until you told it to stop - but of course this meant you had to be even more careful to always restore the old state of affairs when you were done with it. Don't want one error to kill all logging for the rest of the run! (But then there's also zope.testing.loghandler, which seems to be a very similar approach to loggingsupport with a couple of extra convenience methods and the same problem w.r.t. the need to be sure to get rid of it after tests. Maybe Jim didn't notice this one when he wrote loggingsupport? afaict loghandler is older). I don't really have a question. Just wondering if anybody has any thoughts on the "one true way" to deal with this stuff properly. -- Paul Winkler http://www.slinkp.com _______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com