Create base::test::ScopedTaskScheduler.

base/threading/sequenced_worker_pool_unittest.cc

Index: base/threading/sequenced_worker_pool_unittest.cc
diff --git a/base/threading/sequenced_worker_pool_unittest.cc b/base/threading/sequenced_worker_pool_unittest.cc
index 5782af7e767b631bffcb0c3551895ea9a55a2d02..f4f9e600111e7a3308167e30235b20e29305a740 100644
--- a/base/threading/sequenced_worker_pool_unittest.cc
+++ b/base/threading/sequenced_worker_pool_unittest.cc
@@ -287,8 +287,7 @@ class SequencedWorkerPoolTest
   // Destroys and unregisters the registered TaskScheduler, if any.
   void DeleteTaskScheduler() {
     if (TaskScheduler::GetInstance()) {
-      static_cast<internal::TaskSchedulerImpl*>(TaskScheduler::GetInstance())
-          ->JoinForTesting();
+      TaskScheduler::GetInstance()->JoinForTesting();

[robliao, 2016/11/16 21:23:05]

Should this test instead use a scoped_ptr<ScopedTaskScheduler>?

[gab, 2016/11/16 21:29:19]

Being a scheduler test it should probably still test the full scheduler instead
of a single-threaded one?

[robliao, 2016/11/16 21:31:31]

Now that I think about it, is there any harm in allowing callers to specify how
many threads they do want? We default to 1 and if more are needed, you specify
that.

This way we can avoid a lot of folks needing to create a single worker pool with
x number of threads.

[gab, 2016/11/16 21:38:15]

We could definitely have an alternate constructor which allows specifying number
of threads. I'm not convinced we should use test helpers in our own unit tests
though. Testing the full API makes more sense to me here.

[fdoray, 2016/11/16 22:04:45]

Discussed offline. Custom thread count is only useful to test the TaskScheduler
itself. Tests that do that should use the production API to instantiate
TaskScheduler.

       TaskScheduler::SetInstance(nullptr);
     }
   }