Since the network service lives in a separate process, net::URLRequestFilter is not able to intercept requests.
We probably need to provide an interceptor interface for testing purpose and convert those tests to use that interface.
A lot of tests, though probably not all, may be able to use the EmbeddedTestServer server instead (Which provides more functionality than the SpawnedTestServer, which was all that was available when a lot of those tests were written).
Thanks for the information, Matt!
Agreed that using EmbeddedTestServer should work for quite a lot of them.
One thing to consider is that it would be nice if we could minimize the amount changes. Currently there are a few hundreds of failing tests using this class (directly or indirectly).
Another idea is to provide a registration API to ask the network service to hand over the URLLoader request and URLLoaderClient pointer for given URLs, and then the tests can do whatever they want with that request. On top of that we could build some helper class to make it look similar to net::URLRequestFilter.
Maybe it makes sense to look at a few examples and see how big the change would be with both solutions.
The nice thing about switching to embedded test server is that it makes the tests robust against the network API - they no longer depend on it at all, just the embedded test server API.
I think the more relevant count is there are about 30 tests fixtures with failing tests. I'm not sure that switching a test fixture over to using a MockURLLoader would be substantially simpler than just moving it over to the embedded test server.
Test that just use URLRequestMockHTTPJob::GetMockURL, for instance (Like browser_encoding_browsertest.cc), can trivially be switched over to the embedded test server - it support the same mock header format as URLRequestMockHTTPJob does. Things that need to actually inject custom errors and responses may be more problematic.
Comment 1 by bugdroid1@chromium.org
, Oct 20 2017