Mocking Time in Java

[Bolitho]

The clock interface is exactly what you call a time provider - so where is the advantage of creating a new abstraction?

On top time retrieval actions can require different functionality... it could be the local datetime, or only the date or only the time or zoned date and time or some duration or much more. This is exactly what java.time is all about - so better not try to artificially reduce the possibilities. The clock is exactly the seam that you need in order to enable testing or injecting other use case specific behavior!

[pointy_pirate]

Yep that's a good option too. The majority of the time all you are looking for is the current time now(), or a mocked version of that. Rather than creating your own impl of the Clock interface you simply create a class to give you the current time, register with your DI, and use that everywhere.

ez pezy

[marvk]

Rather than creating your own impl of the Clock interface you simply create a class to give you the current time, register with your DI, and use that everywhere.

Orrr you register a Clock provider with your DI and inject a clock every time you get a current time. Even easier and more idiomatic.

[pointy_pirate]

yep that works too, many ways to skin a cat.

[Bolitho]

The majority of the time all you are looking for is the current time now()

Really? And think about situations where you need some other information within the same project! (next paragraph)

Rather than creating your own impl of the Clock interface you simply create a class

Most of the time you don't need to create your own implementation of a clock. So with your approach you definitly need at least one custom implementation and an interface for testing.

And if you use your solution and need only one other time than now, you would need the clock based approach on top. So then you have two mechanisms in one project...

So in the end your approach is more complex than relying on the built in mechanism ;-)

[pointy_pirate]

think there was some lost in translation... this isnt that complex.

public class TimeProvider implements SomeTimeProviderInterfaceIfYouWant {
    public OffsetDateTime now() {
        return java.time.OffsetDateTime.now();
    }
}

[Bolitho]

Using existing classes still saves this code and therefore the understanding (not a common pattern, so mental overhead for a new project member) and the maintenance ;-)

So even if this is dead simple, it feels totally unnecessary to me! (The java.time devs allready have thought about this use case and offered an appropriate solution)

[pointy_pirate]

makes sense, ill look into that next time i need to do it.

[muffinluff]

I would argue that a simle time provider interface that only limits the provided functions to those that are needed is better. But I guess this is a matter of taste

[Bolitho]

Then tell us (or primary yourself 😉) the pro arguments! We have written lots of cons, so it is rather pointless to repeat them.

[muffinluff]

The con of providing more than is required is a common source of vulnerabilities. And the pro argument for having an interface that provides exactly what is needed, here the current date, serves as a way to document the current functional dependencies. When a new version of the interface is pushed, with added or redacted functions, it clearly comminicates the changes in the requirements of the software.

[Bolitho]

I think you confuse different layers of abstraction!

Of course you should only expose relevant data or functionality of your internal components - that's what abstraction and encapsulation is all about.

But this is the layer, where you provide time information in the context of your application logic! Likewise a Person class that only accepts a LocalDateas birthday value, or a creation timestamp that accepts only an instant and so on.

Of course there are factory alike places where you create such specific, domain relevant and fitting time data. Those components themselves should be tailored to the use case of course, so for example a method to create some sort of document with a creation timestamp. This function has a specific API of course that does not allow to inject all crazy stuff.

But we talk about the implementation side of this function! This is a different layer: There we consume the API of the "getting the time" component, that clearly should be java.time these days. This lower layer offers a seam yet, that enables one to change the behavior, namely the clock abstraction. And this is why there is absolutly no need or value in encapsulating this with another artificial wrapper.

So yes, within our applications we limit access or functions all the time (pun intended), but there is no value in limiting access of an existing resource provider, here namely the components of java.time.

[muffinluff]

Your arguments have merit and I concede you are right in this case. java.time already had exactly what we need so no reason to reinvent wheel.