Mocking time in unit tests

[Gabriel Charette]

Hey Joe (CC scheduler-dev FYI),

As mentioned, here's an example of mocking time (delays) in a unit tests via base's brand new ScopedMockTimeMessageLoopTaskRunner: https://codereview.chromium.org/2487343005.

You can combine this with a base::ScopedTaskScheduler to mock time for tasks posted to TaskScheduler.

Thinking about it it's currently slightly convoluted though as you'll need to do the following in this specific order in your test fixture:

 private:

  base::MessageLoop message_loop_;

  base::ScopedMockTimeMessageLoopTaskRunner_ mock_time_task_runner_;

  base::ScopedTaskScheduler scoped_task_scheduler_;

Ideally we could do:

 private:

  base::ScopedTaskScheduler scoped_task_scheduler_;

  base::ScopedMockTimeMessageLoopTaskRunner_ mock_time_task_runner_;

Just like we can currently do:

 private:

  base::TestBrowserThreadBundle thread_bundle_;

  base::ScopedMockTimeMessageLoopTaskRunner_ mock_time_task_runner_;

The reason it's currently convoluted is that ScopedTaskScheduler takes a reference to MessageLoop::task_runner() when it's constructed so the mock needs to already be in place by the time ScopedTaskScheduler is constructed.

+Francois Pierre Doray can probably cook up a cleaner alternative :-).

Cheers,

Gab

[Alex Clarke]

Interesting, TestMockTimeTaskRunner  reminds me of cc::OrderedSimpleTaskRunner.  We should probably rationalize at some point.

--
You received this message because you are subscribed to the Google Groups "scheduler-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scheduler-dev+unsubscribe@chromium.org.
To post to this group, send email to schedu...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/scheduler-dev/CAJTZ7LL%3D-WJUggOPhXEyMiW4xSu_9o13V2abY74rd47skURmEQ%40mail.gmail.com.

[Joe Mason]

The obvious fix would be to get rid of message_loop_task_runner_ and just replace each reference to it with "message_loop_->task_runner()". But I assume the reason message_loop_task_runner_ exists is to ensure that the task runner outlives any tasks posted to it with TestTaskScheduler::PostTask?

What about using message_loop_->task_runner() to access the task runner in all places, but also keep a "saved_message_loop_task_runner_" just for the refcount? Then it could be reffed on first use, in PostTask, rather than in the constructor.

[fdo...@google.com]

On Thursday, February 2, 2017 at 11:16:04 AM UTC-5, Joe Mason wrote:

The obvious fix would be to get rid of message_loop_task_runner_ and just replace each reference to it with "message_loop_->task_runner()". But I assume the reason message_loop_task_runner_ exists is to ensure that the task runner outlives any tasks posted to it with TestTaskScheduler::PostTask?

What about using message_loop_->task_runner() to access the task runner in all places, but also keep a "saved_message_loop_task_runner_" just for the refcount? Then it could be reffed on first use, in PostTask, rather than in the constructor.

Using message_loop_->task_runner() everywhere would work. You would need to store message_loop_->task_runner() in a local variable in TestTaskScheduler::RunTask to restore it at the end of the method (line 207).

[Joe Mason]

Cool, I'll make a patch for that on Thursday when I go back to 20%-ing.