Controlling Time
Disclaimer: This technique does not work outside of programming. Do not try this on your neighbours, kids or pets…
What’s wrong with time dependent tests?
It’s easy to write tests that are far too flaky and intermittent. Worse yet, a quick fix often results in putting a pause to tests that make them drag out longer and longer. Alternatively, unneeded complexity is added to try to do smart things to poll for tests to time out.
What can we do about it?
I’m all about solutions, so I’m out about to outline the secret to controlling time (in at least unit tests). Here’s a situation you might recognise. Or not. Sorry to anyone vegetarian reading this entry.
We have a class called Beef that knows when it’s past its prime using the Joda Time libraries.
package com.thekua.examples;
import org.joda.time.DateTime;
public class Beef {
private final DateTime expiryDate;
public Beef(DateTime expiryDate) {
this.expiryDate = expiryDate;
}
public boolean isPastItsPrime() {
DateTime now = new DateTime(); // Notice this line?
return now.isAfter(expiryDate);
}
}
Surprise, surprise. We also have a unit test for it:
package com.thekua.examples;
import static org.junit.Assert.assertTrue;
import org.joda.time.DateTime;
import org.junit.Test;
public class BeefTest {
@Test
public void shouldBePastItsPrimeWhenExpiryDateIsPast() throws Exception {
int timeToPassForExpiry = 100;
Beef beef = new Beef(new DateTime().plus(timeToPassForExpiry));
Thread.sleep(timeToPassForExpiry * 2); // Sleep? Bleh...
assertTrue(beef.isPastItsPrime());
}
}
Step 1: Contain time (in an object of course)
The first step is to contain all the use of time concepts behind an object. Don’t even try to call this class a TimeProvider. It’s a Clock okay? (I’m sure I used to call it that in the past as well, so don’t worry!). The responsibility of the Clock is to tell us the time. Here’s what it looks like:
package com.thekua.examples;
import org.joda.time.DateTime;
public interface Clock {
DateTime now();
}
In order to support the system working as normally, we are going to introduce the SystemClock. I sometimes call this a RealClock. It looks a bit like this:
package com.thekua.examples;
import org.joda.time.DateTime;
public class SystemClock implements Clock {
public DateTime now() {
return new DateTime();
}
}
We are now going to let our Beef now depend on our Clock concept. It should now look like this:
package com.thekua.examples;
import org.joda.time.DateTime;
public class Beef {
private final DateTime expiryDate;
private final Clock clock;
public Beef(DateTime expiryDate, Clock clock) {
this.expiryDate = expiryDate;
this.clock = clock;
}
public boolean isPastItsPrime() {
DateTime now = clock.now();
return now.isAfter(expiryDate);
}
}
If you wanted to, the step by step refactoring would look like:
- Replace
new DateTime()withnew SystemClock().now() - Replace new instance with field
- Instantiate new field in constructor
We’d use the RealClock in both the code that creates the Beef as well as our test. Our test should look like…
package com.thekua.examples;
import static org.junit.Assert.assertTrue;
import org.junit.Test;
public class BeefTest {
@Test
public void shouldBePastItsPrimeWhenExpiryDateIsPast() throws Exception {
int timeToPassForExpiry = 100;
SystemClock clock = new SystemClock();
Beef beef = new Beef(clock.now().plus(timeToPassForExpiry), clock);
Thread.sleep(timeToPassForExpiry * 2);
assertTrue(beef.isPastItsPrime());
}
}
Step 2: Change the flow of time in tests
Now that we have the production code dependent on an abstract notion of time, and our test still working, we now want to substitute the RealClock with another object that allows us to shift time for tests. I’m going to call it the ControlledClock. Its responsibility is to control the flow of time. For the purposes of this example, we’re only going to allow time to flow forward (and ensure tests use relative times instead of absolute). You might vary it if you needed very precise dates and times. Note the new method forwardTimeInMillis.
package com.thekua.examples;
import org.joda.time.DateTime;
public class ControlledClock implements Clock {
private DateTime now = new DateTime();
public DateTime now() {
return now;
}
public void forwardTimeInMillis(long milliseconds) {
now = now.plus(milliseconds);
}
}
Now we can use this new concept in our tests, and replace the way that we previously forwarded time (with the Thread.sleep) with our new class. Here’s what our final test looks like now:
package com.thekua.examples;
import static org.junit.Assert.assertTrue;
import org.junit.Test;
public class BeefTest {
@Test
public void shouldBePastItsPrimeWhenExpiryDateIsPast() throws Exception {
int timeToPassForExpiry = 100;
ControlledClock clock = new ControlledClock();
Beef beef = new Beef(clock.now().plus(timeToPassForExpiry), clock);
clock.forwardTimeInMillis(timeToPassForExpiry * 2);
assertTrue(beef.isPastItsPrime());
}
}
We can even further improve this test to be more specific by forwarding time by simply adding one rather than multiplying twice.
Step 3: Save time (and get some real sleep)
Although this is a pretty trivial example of a single use of time dependent tests, it shouldn’t take too much effort to introduce this concept to any classes that depend on time. Not only will you save yourself heart-ache with either flaky, broken tests, but you should also save yourself the waiting time you’d otherwise need to introduce, leading to faster test execution, and that wonderful thing of fast feedback.
Enjoy! Let me know what you thought of this by leaving a comment.
Comments(8)
Teams run retrospectives for many different reasons. I’ve found that trying to meet too many goals in a heartbeat retrospective severely limits their effectiveness. When I prepare for retrospectives, I normally ask the sponsor (the person who asked me to facilitate) what they want to achieve. Sometimes they don’t know themselves, so it’s a useful exercise, by itself, to clarify their intended goals. 