Hacker News Reader

Comment by xmprt | Hacker News Reader

It's a shame that the recommended solution is using a C++ trick of templates that doesn't generalize well to other languages.

View on HN

The issue doesn't generalize across languages because they often have other mechanisms that are simpler. In dynamic languages with modules like Javascript, Ruby, or Python, you can usually monkey-patch the system time methods to return what you want. In Java and other JVM languages you'd use dependency injection and then inject a mock into the test. Most other languages use some variant of Approach 1 or Approach 5.

When possible pass the time as an argument and create pure functions or methods.

Reserve Time.now or its equavlent to jobs, controllers, or what not at the edge of your application.

Watch out when using NOW() in your db. Not that you shouldn’t but it might be surprising when you do.

>> Watch out when using NOW() in your db.

Would you be so kind as to elaborate on this?

It was always my thought that NOW() was the more sensible approach as it would capture time in the execution order from a more centralized source (the db server). Where having the origin of a transaction setting at time would get me when, on the origin server the query was initiated.

Not the person to whom you're replying, but I suspect the problem isn't that the database is using NOW(), but that your code being tested will be using an entirely different time.

Bingo.

There is nothing wrong with using NOW(), in of itself, and it maybe the best thing to do.

But it may lead to surprising results when say you have an application that has mocked out time for a specific time, but you get db results for the current time. It introduces another clock into your system.

I have found most of the time we were using NOW() we could pass the time into the query and create a more understandable chain of code.

You mostly want to be consistent. For example if you do a job scheduler which uses NOW() to create job, but a local clock to execute them, then any clock difference between machines will be causing hard-to-debug problems.

If you can't test your code because you use `NOW()` or another form of automatic timestamping in your records, it is on your language or framework. You shouldn't forgo such niceties for limitations imposed by your framework or language, demand better.

We use a "service" class with an internal timer that returns ".now()" and that implements an interface. The .ctor initialize the service's date with Datetime.now().

We use dependency injection wherever the service is required.

With this, we can manage 2 things

1. The service can go faster or slower than the real time by changing the timer's interval so we can simulate time depend behaviour in the app while testing.

2. We can mock the service when testing with a simple counter that's increased each time “.now()" is called.

well, in the latest .NET 8, for any of the .NET languages there is

https://learn.microsoft.com/en-us/dotnet/core/whats-new/dotn...

Though most people were rolling their own version of it before this.

Reply on news.ycombinator.com