In my opinion, this should be fixed by specifying a non-existing directory as a parameter to CreateBrowserPolicyConnector() which then is wired through to ConfigDirPolicyLoader().

https://cs.chromium.org/chromium/src/chrome/test/base/testing_browser_process.cc?sq=package:chromium&dr&rcl=1469171820&l=151

@Thiemo: I've looked into the idea of solving it by passing a different parameter in TestingBrowserProcess, but TestingBrowserProcess is not used in browser tests, so it would not solve the issue Lutz originally had.

My current proposal is to use PathService::Override to change directory, both for unit tests and browser tests / see https://codereview.chromium.org/2612733003/ .

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/6edddec42dae4c5797b642f59580a8c7024c1b6a

commit 6edddec42dae4c5797b642f59580a8c7024c1b6a
Author: pmarko <pmarko@chromium.org>
Date: Wed Jan 11 10:25:18 2017

Machine-local policy files should not affect tests

Override location of machine-local policy directory for both unit tests
and browser tests. This makes sure that any policy data the machine has
does not affect the test results.

BUG= 630614 

Review-Url: https://codereview.chromium.org/2612733003
Cr-Commit-Position: refs/heads/master@{#442852}

[modify] https://crrev.com/6edddec42dae4c5797b642f59580a8c7024c1b6a/chrome/test/base/test_launcher_utils.cc
[modify] https://crrev.com/6edddec42dae4c5797b642f59580a8c7024c1b6a/chrome/test/base/testing_browser_process.cc

Incidentally, I've found the method policy::PolicyServiceIsEmpty in policy_test_utils.cc, which is used in three places like this:

ASSERT_TRUE(PolicyServiceIsEmpty(g_browser_process->policy_service()))
    << "Pre-existing policies in this machine will make this test fail.";

Pro leaving these in:
- there could still be pre-existing policies e.g. on Windows through Registry

Con leaving these in:
- to be consistent, that precondition should probably be in many tests
- we now ignore the usual machine-local policy directories on POSIX (-Mac) systems at least.

What do you think?

Actually, there's probably no point in removing these - they don't hurt and effectively, the probability that these would be triggered has been reduced by implementing this, so I'd say let's leave those as they are.

If you disagree, please re-open the bug.