ProfileSyncServiceTest refactoring

chrome/browser/sync/glue/sync_backend_host_impl_unittest.cc

Index: chrome/browser/sync/glue/sync_backend_host_impl_unittest.cc
diff --git a/chrome/browser/sync/glue/sync_backend_host_impl_unittest.cc b/chrome/browser/sync/glue/sync_backend_host_impl_unittest.cc
index 9f5693fe378563881d48de9abcfa993c71301c1a..217ed048bdca546c5c4ea19e1f5c0ab123e8ee0d 100644
--- a/chrome/browser/sync/glue/sync_backend_host_impl_unittest.cc
+++ b/chrome/browser/sync/glue/sync_backend_host_impl_unittest.cc
@@ -6,6 +6,7 @@
 
 #include <cstddef>
 
+#include "base/file_util.h"
 #include "base/location.h"
 #include "base/memory/scoped_ptr.h"
 #include "base/message_loop/message_loop.h"
@@ -687,6 +688,21 @@ TEST_F(SyncBackendHostTest, DownloadControlTypesRestart) {
             fake_manager_->GetAndResetConfigureReason());
 }
 
+// It is SyncBackendHostCore responsibility to cleanup Sync Data folder if sync
+// setup hasn't been completed. This test ensures that cleanup happens.
+TEST_F(SyncBackendHostTest, TestStartupWithOldSyncData) {
+  const char* nonsense = "slon";
+  base::FilePath temp_directory =
+      profile_->GetPath().AppendASCII("Sync Data");
+  base::FilePath sync_file = temp_directory.AppendASCII("SyncData.sqlite3");
+  ASSERT_TRUE(file_util::CreateDirectory(temp_directory));
+  ASSERT_NE(-1, file_util::WriteFile(sync_file, nonsense, strlen(nonsense)));
+
+  InitializeBackend(true);

[rlarocque, 2013/11/13 18:58:35]

I think InitializeBackend() will instantiate a FakeSyncManager.  The
FakeSyncManager has no syncable::Directory.  So no one will bother to create an
on-disk sync DB in this test.

I guess that's OK.  The test only promises to test the directory cleanup code,
and it certainly does that.

[pavely, 2013/11/18 19:26:57]

Yes, you are right. It doesn't test creation of sync db.

+
+  EXPECT_FALSE(base::PathExists(sync_file));
+}
+
 }  // namespace
 
 }  // namespace browser_sync