Tids-APIet f.o.m. Java 8 har konseptet Clock som gjør at man kan styre tidspunkter som resolves "fra miljøet/systemklokka" i tester. JodaTime gjør dette ved at man kaller på noen statiske metoder som globalt styrer hvordan JodaTime resolver tidspunkt hver gang man typisk ber om DateTime.now() eller tilsvarende. I Java Time API bruker man i stedet en instans av Clock. Jeg er mest fan av Java sin approach, selv om den kan virke mer tungvinn hvis man er vandt med "umiddelbarheten" ved å bare kalle på en statisk utility som overstyrer klokka globalt.
Grunner til at jeg foretrekker klokke-instans fremfor static metode for global styring er:
- man ser tydeligere at en klasse faktisk har en avhengighet til tiden, siden den må ha et eget
Clock-felt, ev ta det inn i en metode. - dersom det føles rart å ta inn en
Clockså er det ofte også feil, og man bør ta inn en spesifikk tidsverdi som er resolvet utenfra. Det er ikke like lett å identifisere med biblioteker som bare lar deg statisk resolve "nå", siden det er så convenient. - ved å bruke en klokke-instans åpner det opp for parallell kjøring av tester. Dette er umulig (innenfor samme JVM) med JodaTime sin måte å kontrollere tiden på.
Klokke-instanser er heller ikke et nytt design pattern. Dette fikk jeg fikst ferdig servert og godt innarbeidet fra min første dag på jobb i 2007. Velkommen etter Java.
Men nok prat. Det som ikke følger med JDKen er faktisk en sånn fully-featured testklokke som lar deg kontrollere hva man får fra Clock.instant(). Det går fint å implementere en slik selv ved å subklasse Clock, og la tester kontrollere klokkeinstansen som brukes, men det er jo enda bedre om noen ™️ allerede har gjort dette? På Digipost har vi et lite general purpose bibliotek som heter Digg, som bl.a. inneholder en slik klokke: ControllableClock. Det er også litt dritt å lage en egen Clock-subklasse da man faktisk må implementere hele tre abstrakte metoder 🙄.
Java har forsåvidt selv mulighet for å instansiere en fryst klokke hvor Clock.instant() vil alltid bare gi et fast tidspunkt, men ofte trenger man å simulere et tidsforløp i tester. Dette kan man gjøre enten med ControllableClock.timePasses(..) eller ControllableClock.set(..).