Re-enable PostDelayed test for TaskQueue on Windows.
The requirements have been relaxed a little bit which should allow the test to pass on our VMs that run the tests.
BUG=6610
Review-Url: https://codereview.webrtc.org/2458713005
Cr-Commit-Position: refs/heads/master@{#14836}
diff --git a/webrtc/base/task_queue_unittest.cc b/webrtc/base/task_queue_unittest.cc
index 3af337d..5fac62d 100644
--- a/webrtc/base/task_queue_unittest.cc
+++ b/webrtc/base/task_queue_unittest.cc
@@ -91,13 +91,7 @@
EXPECT_TRUE(event.Wait(1000));
}
-// Currently flaky on Windows. See issue 6610.
-#if defined(WEBRTC_WIN)
-#define MAYBE_PostDelayed DISABLED_PostDelayed
-#else
-#define MAYBE_PostDelayed PostDelayed
-#endif
-TEST(TaskQueueTest, MAYBE_PostDelayed) {
+TEST(TaskQueueTest, PostDelayed) {
static const char kQueueName[] = "PostDelayed";
TaskQueue queue(kQueueName);
@@ -106,8 +100,11 @@
queue.PostDelayedTask(Bind(&CheckCurrent, kQueueName, &event, &queue), 100);
EXPECT_TRUE(event.Wait(1000));
uint32_t end = Time();
- EXPECT_GE(end - start, 100u);
- EXPECT_NEAR(end - start, 200u, 100u); // Accept 100-300.
+ // These tests are a little relaxed due to how "powerful" our test bots can
+ // be. Most recently we've seen windows bots fire the callback after 99ms,
+ // which is why we have a little bit of leeway backwards as well.
+ EXPECT_GE(end - start, 95u);
+ EXPECT_NEAR(end - start, 195u, 100u); // Accept 95-295.
}
TEST(TaskQueueTest, PostMultipleDelayed) {
