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
Zope3-dev mailing list

Reply via email to