Another drive-by, because I had to do something similar in crrev.com/1917073002 to listen to console messages :) I see that ConsoleWebContentsDelegate used in the current tests is very similar to ConsoleObserverDelegate from cr/1917073002, so it seems you could use that instead? And perhaps we should rename ConsoleObserverDelegate to ConsoleMessageWaiter or something more searchable.

That aside, it seems a bit odd to me to have to keep track of IPCs in unit tests. Wouldn't it be cleaner to delegate logging of the console message to a mock class instead?

Oh, cool, yes we should be using ConsoleObserverDelegate instead.

> Wouldn't it be cleaner to delegate logging of the console message to a mock class instead?

Do you mean that RenderFrameHostImpl::AddMessageToConsole() should send the message to a class that sends the IPC, so that the class can be mocked? Or that ChromeSecurityStateModelClient should use a separate class (that can be mocked) to send the console message instead of calling the RFH directly?

To me, the main limitation is that a test should be able to synchronously check that a console message was logged, because otherwise we can't really test that a console message was *not* logged when it shouldn't have been.

It's a bit hacky, but we could get around that by logging a final message at the end and checking that only the final message appears, right?

> Do you mean that RenderFrameHostImpl::AddMessageToConsole() should send the message to a class that sends the IPC, so that the class can be mocked? Or that ChromeSecurityStateModelClient should use a separate class (that can be mocked) to send the console message instead of calling the RFH directly?

The latter. You can wrap |web_contents_->GetMainFrame()->AddMessageToConsole()| call in a ConsoleDelegate class. Test code then uses a MockConsoleDelegate which just keeps track of which messages were logged. That way you should be able to synchronously test for an unexpected message.

Ok, yeah, I think either of those approaches would work (waiting for a dummy message at the end, or a MockConsoleDelegate.)

Re-titling and -labeling to reflect the various options we can do to simplify these tests:

- Use the pre-existing ConsoleObserverDelegate instead of re-inventing the wheel.
- Log a dummy message and wait for it to test that a console message isn't added.
- Or have ChromeSSMClient log to a ConsoleDelegate that can be mocked for tests.