Currently the network service is lazy-loaded into a few leaky singletons in https://cs.chromium.org/chromium/src/content/browser/network_service_instance.cc

The leaked state can cause problems with unit tests. The main problem right now is that the network service creates its own NetworkChangeNotifier (NCN) if one doesn't already exist, but since the network service leaks, its NCN never gets deleted. Any later tests that want to create their own NCN will fail because NCN expects there to only be a single instance. There are workarounds to this for now, but ideally we should just make the network service clean itself up.

The current idea is to replace the static functions in network_service_instance.cc with methods in a new NetworkServiceInstance class. This class will probably still need to be accessed statically, but the object could be owned by BrowserMainLoop or some other high level class.

Wiring NetworkServiceInstance into unit tests would be a bit tricky because the network service has to start on the IO thread, and there's a ThreadChecker that checks that it's destroyed on the IO thread as well. In unit tests, TestBrowserThreadBundle is the thing that creates and destroys the IO thread, which means the network service can't outlive it. To get around this, we're thinking of having a ScopedNetworkServiceInstance object that you'd include as a member of unit tests that directly or indirectly depend on the network service, and if you call any code that uses the network service without creating this scoped instance, the test will fail. This makes test dependencies more explicit, and provides a non-static mechanism for tests to control network service behavior. The main problem with this approach is that TestingProfile indirectly depends on the network service, and a lot of tests create a TestingProfile. A quick test showed that about 2/3 of all unit_tests, spanning more than 500 files depend on the network service and would have to be updated to include the ScopedNetworkServiceInstance.