[Webkit-unassigned] [Bug 46635] test-webkitpy should have logging configured differently

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Oct 14 16:13:31 PDT 2010


https://bugs.webkit.org/show_bug.cgi?id=46635





--- Comment #14 from Dirk Pranke <dpranke at chromium.org>  2010-10-14 16:13:31 PST ---
Registering its own handler doesn't help, I don't think (since we're already capturing stdout and stderr). Note that if you change test_configure_logging to use OutputCapture(), you'll still get the message printed to stderr (since test-webkitpy installed its own logger that keeps its own reference to the original stderr).

So, as you say, you could change OutputCapture.capture_output() to remove any installed handlers and restore them during restore_output(). I'm not a big fan of that change, because it has OutputCapture messing with stuff it doesn't own, and the logging modules are not really designed to enable this, so the code has to poke at internals to accomplish its mission. Note that printer.configure_logging() actually originally did what you are suggesting, but it proved to be really fragile, possibly because I wasn't being aggressive enough about removing *all* handlers. 

So, we're really looking at different things here.

1) capturing anything that is logged to stdout/stderr by test code. OutputCapture does this just fine today.

2) preventing anything from actually getting logged to stdout/stderr during a test that is using OutputCapture.

3) treating anything getting logged to stdout/stderr if a test isn't using OutputCapture as an error

I think (2) and (3) are somewhat at odds with each other. The only comprehensive way to prevent logging outside of stdout/stderr would be to capture stdout/stderr at the beginning of the test run, but somehow still allow the unittest framework itself to log stuff. But, if you do that, you would also have to somehow inject code after each test to see if anything did get incorrectly logged to stdout/stderr.

As an alternative, if you leave stdout/stderr alone at the beginning, then you don't have to do anything special to the unittest subsystem, and you can rely on us actually seeing garbage in the test-webkitpy output to detect bugs. But, you still need my patch to turn off the channel through the initial webkitpy handler. 

And, you need *some* handler to be installed, or you'll get spurious "no handlers found for module x.y.z" messages when things do call into the logging system.

So, I think my patch is the right way to get what you're looking for. Does that make sense?

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list