Hacker News Reader

Comment by dathinab | Hacker News Reader

in general

- generating test data in a realistic way is often better then hard coding it (also makes it easier to add prop testing or similar)

- make the current time an input to you functions (i.e. the whole old prefer pure functions discussion). This isn't just making things more testable it also can matter to make sure: 1. one unit of logic sees the same time 2. avoid unneeded calls to `now()` (only rarely matters, but can matter)

View on HN

Similarly, I like .NET's TimeProvider abstraction [1]. You pass a TimeProvider to your functions. At runtime you can provide the default TimeProvider.System. When testing FakeTimeProvider has a lot of handy tools to do deterministic testing.

One of the further benefits of .NET's TimeProvider is that it can also be provided to low level async methods like `await Task.Delay(time, timeProvider, cancellationToken)` which also increases the testability of general asynchronous code in a deterministic sandbox once you learn to pass TimeProvider to even low level calls that take an optional one.

[1] https://learn.microsoft.com/en-us/dotnet/standard/datetime/t...

Java has an interface named InstantSource for this purpose: https://docs.oracle.com/en/java/javase/17/docs/api/java.base...

Paradoxically, InstantSource may have a delay. ;)

Also, if you do use `now()` in this case you can always do `now() + SomeDistantDuration`

Reply on news.ycombinator.com