27/05/2026
In my examples in unit testing class, I always show an expiration calculation code. Checking if the current date is before or after a set expiration date.
And I ask about edge cases. And the people look at the code, and discuss and they come up with interesting cases.
And they write tests and review them, and run them, and everyone's happy, because now we have tests that will cover us in case of a code change. They will alert us if the code no longer does what it intends to do.
And you look at those tests and you want to almost hug them.
Until one test starts getting iffy. It mostly passes. But sometimes, in the dark of night it fails. And you look at the code - it didn't change. And the test - didn't either. And you run it again, and it passes, of course.
The only problem, is that in the dark of night, dates tend to change. And that may happen as our test runs, although mostly it doesn't run around midnight.
But who thinks about time, at the time of writing the tests?
There's a reason we mock dates and times to test logic. We want control and consistency. But system tests - API, UI - they don't have that luxury. And when they run, even if we don't intend it, may have an impact on the result.
Let me turn this to you. What's your craziest time related testing story?
