Mock base::TimeTicks::Now() in tests |
|
Issue descriptionWith the advent of base::test::ScopedTaskEnvironment we're getting close to having the ability to easily mock time in unit tests (browser tests and other integration tests will require more thought). Currently we have ScopedTaskEnvironment::MainThreadType::MOCK_TIME but are planning to extend that to all thread types soon (UI/IO). Once we have that MOCK_TIME can graduate from being a MainThreadType to be its enum parameter (i.e. TimeSourceType::Mock). At that point, we can mock time for all delayed tasks (i.e. beyond main thread and, specifically, in base::TaskScheduler). There's still a problem for tests that use base::TimeTicks::Now() directly (and often it's product code that does so so it's hard to workaround and adding Foo::SetTickClockForTesting() everywhere is ugly). base::Timer is a typical example that will repost based on realtime TimeTicks::Now() when restarted. As such, the ultimate long-term solution is to have ScopedTaskEnvironment extend its MockTickClock to be the source of base::TimeTicks::Now(). But first we need to complete issue 708584 (bring all the above functionality to ScopedTaskEnvironment). This issue tracks the vision beyond that.
,
Nov 15
I like the idea of overriding TimeTicks::Now() from the task environment. It might let us simplify some of the virtual time logic in the sequence manager.
,
Nov 15
I don't think anything would change in the sequence manager. Anyway AutoAdvancingVirtualTimeDomain already mocks time, so I think it should be relatively simple to do this in ScopedTaskEnvironment too. BTW in headless we had to allow JS's view of time to advance when called repeatedly because there's web content that sits in a loop waiting for Date.now to reach a certain point. Hopefully that won't be an issue for C++ code, but something to bear in mind with tests. I wonder if we will need to synchronise renderer time with the browser when running browser tests with mock time?
,
Nov 15
It might be worth looking at issue 866930 (and the corresponding doc, https://drive.google.com/u/0/open?id=1Xjc67VhY-WCt4S2PXyDpyg-E7IZAZf3LRfHu31ttXUo) where I tried to change how we mock time in tests just to make sure that we don't run into the same hurdles again. I'm not familiar with whether base::test::ScopedTaskEnvironment resolves the issues I ran into. Basically, my problem was that the testing environment lived in the same process as the code under test and relied on the same pathways (TimeTicks::Now()). This caused the testing environment to fail in surprising ways when we tried to globally override the time in the test. Hopefully this is exactly what ScopedTaskEnvironment can fix, but I just wanted to point out that this was an issue in the past.
,
Nov 17
@charliea : right, I've been assuming we'll run into that (test timeouts need to be realtime). This bug is just a tracker since a few people have asked me about the plans, but I haven't actually started to look into this yet. Thanks for the pointers, it'll be useful when I get there. |
|
►
Sign in to add a comment |
|
Comment 1 by s...@chromium.org
, Nov 14