This appears to have broken in https://ci.chromium.org/buildbot/chromium.mac/ios-simulator/29858, according to the bot logs.

I bet this is https://chromium-review.googlesource.com/c/chromium/src/+/924759. 

If we mock out NSDate but don't put the original implementation back, then WaitUntilConditionOrTimeout() could end up failing because it's trying to call those NSDate APIs.

I can reproduce locally by running the entire ios_chrome_unittests test suite, or by passing --gtest_filter=ReauthenticationModuleTest*:TextToSpeechListenerTest*.

The failing tests pass on retry because they're run by themselves in a separate process.

The OCMock docs say that you have to dealloc the mock object in order to restore the original implementations.  I bet that's not happening because the mock is being autoreleased but we're not subclassing PlatformTest to give ourselves an autorelease pool.

FYI this was pretty easy to track down because:

1) The flakiness dashboard showed that some tests were failing 100% of the time.
https://test-results.appspot.com/dashboards/flakiness_dashboard.html#testType=ios_chrome_unittests&showExpectations=true&tests=TextToSpeechListenerTest.ValidAudioDataTest

2) From there it was easy enough to go back through bot logs to find the first run in which these tests started failing.
https://ci.chromium.org/buildbot/chromium.mac/ios-simulator/29858

3) And then go through the set of commits looking for anything that might be related.


Kudos to sdefresne for noticing this.  If we had sat on it for a week, the bot logs might have been deleted and then it would've been a pain to track down.

Looks like we should revert that CL and investigate how we can safely decouple the implementation from the real NSDate (maybe through injection) instead of relying on mocking some class methods.

Subclassing PlatformTest fixes the issue, so that's what I've done in https://chromium-review.googlesource.com/c/chromium/src/+/936222.

Further decoupling from NSDate seems like a reasonable idea, but it's not urgent anymore.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/bd061a082fcf108b2fb2898886a6155cda2f02b2

commit bd061a082fcf108b2fb2898886a6155cda2f02b2
Author: Rohit Rao <rohitrao@chromium.org>
Date: Sun Feb 25 21:11:37 2018

[ios] Makes ReauthenticationModuleTest inherit from PlatformTest.

These tests use OCMClassMock() to mock out an NSDate class method.  The
OCMock documentation states that behavior is undefined if multiple
objects try to mock the same class simultaneously.  The documentation
also states that the mock object must be deallocated in order to restore
the original method implementations.

I suspect that the autorelease pool is never being drained and therefore
the mock object stays alive past the end of these tests.  This is
calling subsequent tests to fail, because NSDate no longer returns the
correct date.

Inheriting from PlatformTest wraps each test in an autorelease pool,
which appears to be enough to get the tests passing again.

BUG= 815189 
TEST=TextToSpeechListenerTest.ValidAudioDataTest passes on the bots.

Cq-Include-Trybots: master.tryserver.chromium.mac:ios-simulator-cronet;master.tryserver.chromium.mac:ios-simulator-full-configs
Change-Id: I0d8383b0d1f476ff2ab9840fff384f7b4aeb2dc3
Reviewed-on: https://chromium-review.googlesource.com/936222
Reviewed-by: Justin Cohen <justincohen@chromium.org>
Commit-Queue: Rohit Rao <rohitrao@chromium.org>
Cr-Commit-Position: refs/heads/master@{#539050}
[modify] https://crrev.com/bd061a082fcf108b2fb2898886a6155cda2f02b2/ios/chrome/browser/ui/settings/reauthentication_module_unittest.mm

I remember adding a presubmit check to fix this in the downstream tree. Found out that it was reverted, so let's add a check upstream then.