Fake time, also called mocked time or a fake clock, is a testing technique where the software reads the current time from a controllable time provider instead of the real system clock. Tests can then speed time up, slow it down or jump to a chosen date, so time-dependent behaviour can be checked without waiting for it to happen.
Why it matters: Many applications depend on time in complex ways. Tests run far faster than real use, so features that unfold over hours or days, such as request expiry or multi-day transaction processing, can be inaccessible or behave oddly under test. Controlling time makes those scenarios reachable and repeatable.
In practice: Teams replace direct calls to the system time with a central time provider that tests can adjust. The change must be consistent across every component in the tested environment, which gets harder moving from unit to integration to end-to-end tests.
Examples:
- Moving the clock forward three days to check that a banking transaction completes and its status changes correctly.
- Reducing an hour-long session expiry to a few seconds so a negative test for expired tokens can run straight away.
- Setting the date to 29 February or the night clocks change to find leap year and daylight saving bugs.
Common pitfalls:
- Faking time in one service but not another, so components disagree about the current time and produce failures that never happen in production.
- Leaving hidden calls to the real system clock in the code, which quietly bypass the time provider and make tests unpredictable.
How do you test code that depends on the current date? Pass the time in from a provider or clock object that tests can control, rather than reading the system clock directly, then set it to the dates you need to check.
Is fake time the same as slowing down a system? No. Fake time usually speeds tests up, while slowing parts of a system down, such as simulating a slow network, is a separate technique for exposing timing failures and race conditions.
