Dynamic updating recent menu for tabs from other devices.

chrome/browser/sync/profile_sync_test_util.h

 // Copyright (c) 2012 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_BROWSER_SYNC_PROFILE_SYNC_TEST_UTIL_H_
 #define CHROME_BROWSER_SYNC_PROFILE_SYNC_TEST_UTIL_H_
 
 #include <memory>
 #include <string>
 
@@ skipping 40 matching lines @@
 
 // A utility used by sync tests to create a TestingProfile with a Google
 // Services username stored in a (Testing)PrefService.
 std::unique_ptr<TestingProfile> MakeSignedInTestingProfile();
 
 // Helper routine to be used in conjunction with
 // BrowserContextKeyedServiceFactory::SetTestingFactory().
 std::unique_ptr<KeyedService> BuildMockProfileSyncService(
     content::BrowserContext* context);
 
+std::unique_ptr<KeyedService> BuildNiceMockProfileSyncService(

[Peter Kasting, 2017/03/28 21:38:39]

Nit: Add comment about how this is distinct from the function just above, and
when callers would use one versus the other

And really, I'm not clear on this either.  Why does the Mac test use the
nicemock version but the other test doesn't?  Why should the niceness of the
mock ever matter -- do we error on uninteresting calls in the mac test for some
reason?  This addition seems suspicious.

[sath, 2017/03/29 06:26:15]

Before my changes in class RecentTabsSubMenuModel class AppMenuControllerTest
used a real instance ProfileSyncService which started inside
CocoaProfileTest::SetUp(). Some observers  was added inside
CocoaProfileTest::SetUp() in the real instance  ProfileSyncService. It worked
because RecentTabsSubMenuModel used instance of OpenTabsUIDelegate passed
through constructor.
When I got rid of OpenTabsUIDelegate parameter in constructor
RecentTabsSubMenuModel I always need to have a mock of  ProfileSyncService with
mock GetOpenTabsUIDelegateMock in order to return testing instance of
SessionsSyncManager if synchronization is enabled.
So I needed to use AddTestingFactories(...) to create mock ProfileSyncService
instead of real instance inside CocoaProfileTest::SetUp(). But in this case I
got many "unintresting call methods for mock". And I decided to create NiceMock
of ProfileSyncService.

[Peter Kasting, 2017/03/29 07:20:45]

Did the "uninteresting call"s result in test failures, or just output spew?

If the latter, I would probably avoid adding this method.  I'd only do it if you
need it to fix failures.

The other option is to just make the default BuildMockProfileSyncService()
return a NiceMock instead of a normal Mock, which seems OK too.

+    content::BrowserContext* context);
+
 #endif  // CHROME_BROWSER_SYNC_PROFILE_SYNC_TEST_UTIL_H_