How to unit test code that depends on time

Original Article ↗ Hacker News Discussion ↗

Testing code that depends on the current time raises deeper design questions about how software should interact with external state. Commenters compare approaches such as dependency-injected clocks, passing timestamps into pure functions, monkey‑patching time APIs, and system-level shims like libfaketime, noting that choices differ by language and by whether you’re writing unit or integration tests. Many argue that treating time as a first-class dependency improves testability and architecture, while others point out hard limits when third‑party libraries, performance characteristics, or real hardware timing are involved.

Core principle: treat time as a dependency

  • Many argue “time is a dependency like any other.”
  • Recommended patterns: inject a clock/timer interface, pass a now() function, or pass explicit timestamps into logic.
  • Preference order (for some):
    • Best: logic takes time data as an argument.
    • Next: logic takes a time-producing function.
    • Then: inject a clock/timer object via DI.

Language- and framework-specific tooling

  • C++ article seen as narrow; other languages offer easier mechanisms.
  • Dynamic languages (JS, Python, Ruby) often monkey-patch time or use libraries: Jest fake timers, freezegun/time-machine (Python), Timecop/Rails travel_to (Ruby).
  • Java commonly injects Clock. .NET 8 adds TimeProvider and FakeTimeProvider. Go code often passes time.Now as a function parameter.

Databases and multiple clocks

  • Using NOW() in SQL is not inherently bad but can introduce a second clock.
  • Problems arise when app time is mocked but DB time is real, or when scheduler and executor use different machines/clocks.
  • Many suggest passing the time into queries for consistency.

Third‑party libraries and testing scope

  • If code you don’t control calls real time, injecting your own clock may be impossible.
  • Suggested responses:
    • Use integration tests and accept slower/less isolated checks.
    • Wrap the library behind your own interface and provide a test implementation.
    • Debate over whether first-party tests should ever explicitly test third‑party behavior; strong disagreement here.

System-level time interception

  • Tools like libfaketime (and similar experimental libraries) intercept system calls or vDSO functions to fake time at the process level.
  • Seen as powerful but sometimes awkward (env vars, LD_PRELOAD) and overkill for simple unit tests.

Integration tests that depend on time

  • Naive sleep()-based tests are slow and flaky under load.
  • Common workaround: poll for observable side effects instead of waiting fixed durations.
  • Other proposals: faketime at process level, tenant-local clocks controllable by the test harness, or “test clocks” injected at a higher architectural level.

Mocks, DI complexity, and critique of the article

  • Some worry that injecting clocks and mocks adds dependencies and makes code harder to work with; others say injected clocks greatly aid both testing and debugging.
  • Mocks are viewed as fine if they test public, well-defined interfaces and are not overused.
  • A few criticize the article as too simplistic: real time-sensitive systems (performance, hardware, multimedia) have challenges that go far beyond clock factories and templates.