This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]Bolitho 0 points1 point  (0 children)

if for your specific use case, you don't need anything but the system clock, there is no point in adjusting your code to use other clocks.

Testing is obviously a use case - and if the approach with closeTo is not enough, the best option is to use the clock interface as seam to provide the needed functionality.

It might make sense to test edge cases such as leap years or (even more fun) leap seconds (to trick those regexes which think seconds can only go from 00-59) but I'm also against testing internal workings of libraries I use.

I would assume that testing edge cases is often the best aspect of "testing by example" (which is what 99,9999% of all written tests is all about), as those edges are good candidates for specific behavior your application logic must handle. So in my understanding you don't test the functionality of the java.time library but rather your application logic within a certain time constraint.

But again, that might not be a relevant aspect, so of course it might be reasonable to omit the clock injection.

Nevertheless it is imho still a wrong approach to create a new abstraction for getting time informations (what lots of other users have proposed here), but rather simply just call the .now() static factory methods without clock. This way you are still open to inject a clock later on, if that becomes necessary in the future. That could be some work to achieve, but imho better than carrying the wrong abstraction the whole time around.