mac: Swizzle out +[NSBundle mainBundle] for in process browser tests.

chrome/test/base/scoped_bundle_swizzler_mac.h

+// Copyright 2015 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#ifndef CHROME_TEST_BASE_SCOPED_BUNDLE_SWIZZLER_MAC_H_
+#define CHROME_TEST_BASE_SCOPED_BUNDLE_SWIZZLER_MAC_H_
+
+#include "base/macros.h"
+#include "base/memory/scoped_ptr.h"
+
+namespace base {
+namespace mac {
+class ScopedObjCClassSwizzler;
+}  // namespace mac
+}  // namespace base
+
+// Within a given scope, swizzles the implementation of +[NSBundle mainBundle]
+// to return a partial mock of the original bundle. This partial mock has a
+// custom bundle identifier.
+// Since this class swizzles a class method, it doesn't make sense to have more
+// than one instance of this class in existence at the same time.
+class ScopedBundleSwizzlerMac {

[Robert Sesek, 2015/06/26 22:36:54]

How does this interact with the bundle faking out in base/mac/foundation_util.h?

[erikchen, 2015/06/26 23:14:53]

Bundle faking works like this:
1) All Chrome code calls a Chrome-specific getter to access a bundle.
2) The getter is generally something like:
"""
  if (g_override_framework_bundle)
    return g_override_framework_bundle;
  return [NSBundle mainBundle];
"""

So this causes a behavior change if [NSBundle mainBundle] would have returned a
different bundle ID. Given that this is only used by tests (ensured by the
include of OCMock and DEPs files), this shouldn't be a problem.

[Robert Sesek, 2015/06/30 22:21:07]

OK. Can you add some commentary as to when one would use that versus (or in
conjection with) this?

[erikchen, 2015/07/06 22:00:06]

Done.

+ public:
+  ScopedBundleSwizzlerMac();
+  ~ScopedBundleSwizzlerMac();
+
+ private:
+  scoped_ptr<base::mac::ScopedObjCClassSwizzler> class_swizzler_;
+  DISALLOW_COPY_AND_ASSIGN(ScopedBundleSwizzlerMac);
+};
+
+#endif  // CHROME_TEST_BASE_SCOPED_BUNDLE_SWIZZLER_MAC_H_