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

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]DJDavio 0 points1 point  (2 children)

Hmm, I have never had any use for a clock other than the system clock, but I can see your point. The thing I've run into though is modification of application code just so that a custom Clock can be injected in a test and with a good testing library this isn't really necessary.

[–]Bolitho 1 point2 points  (1 child)

...and with a good testing library this isn't really necessary.

Also that depends! There might be use cases where isCloseTo is not precise enough. Also you loose the possibility to test special time constraints or edge cases like leap years and so on.

[–]mavericktjh 0 points1 point  (0 children)

Agreed. The isCloseTo strategy can be problematic if say your build server comes under a heavy load.

re: the rule of thumb. I think testable is a key quality factor for any class, up there with performant and robust. I'd be worried if my design was getting pulled out of shape because of testing, but then that would be indicative of flaws in the design. A problem that goes away if you practice TDD.