[nine_k]

During my ~60 months inside Google, these nuggets sometimes proved to be useful, telling about a newly available tools (e.g screenshot diffing in UI tests), common pitfalls (like mixing up dates from different systems with and without timezone), common best practices (don't use `now()` in test, instead, imitate the flow of time using...). These are just off the top of my head after several years outside Google.

Nothing mind-blowing or earth-shattering. A number of useful things to learn at these 30-60 seconds when you can't read anything more interesting, though.

[OneMoreGoogler]

I agree, it's between useful and harmless.

But who considered someone taking a piss and thought "that time could be better utilized?"

[dhhdhdsbdb]

I think this is a great way to spread info. You're there, probably doing nothing. And everyone has to pee!

[natrik]

Could you expand more on not using now()

[jumpingmice]

Using the real-time clock makes your test impossible to reproduce. Using a mock clock leads to reproducible tests. Same with calls to PRNGs: these should be injected so your test failures can be reproduced.

[nine_k]

Your now() in tests depends on current moment.

You cannot test how your code behaves when midnight passes, when daylight saving time changes either way, when it's 29th of February, etc.

More importantly, you cannot reliably (let alone quickly) test how your retry and timeout handling works, especially if two threads interact, or when you do (stubbed or mocked) remote API calls. All these things are the daily bread when working with Google's services, and basically at any setup with multiple (micro)services.

[MrGilbert]

The first time I implemented an "IDateTimeService" in one of our applications, I was greeted with disbelief by my colleagues. Once I challenged them in running tests for certain edge cases, their mind shifted from "well, we cannot test that then" to "makes totally sense".